[med-svn] [Git][med-team/python-pycosat][upstream] New upstream version 0.6.6+dfsg
Lance Lin (@linqigang)
gitlab at salsa.debian.org
Thu Nov 30 15:40:02 GMT 2023
Lance Lin pushed to branch upstream at Debian Med / python-pycosat
Commits:
48345dbd by Lance Lin at 2023-11-30T19:41:10+07:00
New upstream version 0.6.6+dfsg
- - - - -
23 changed files:
- + .authors.yml
- + .github/ISSUE_TEMPLATE/0_bug.yml
- + .github/ISSUE_TEMPLATE/1_feature.yml
- + .github/ISSUE_TEMPLATE/epic.yml
- + .github/PULL_REQUEST_TEMPLATE.md
- + .github/workflows/cla.yml
- + .github/workflows/issues.yml
- + .github/workflows/labels.yml
- + .github/workflows/lock.yml
- + .github/workflows/project.yml
- + .github/workflows/stale.yml
- .gitignore
- + .mailmap
- + AUTHORS.md
- − CHANGELOG
- + CHANGELOG.md
- CODE_OF_CONDUCT.md
- HOW_WE_USE_GITHUB.md
- + MANIFEST.in
- + RELEASE.md
- pycosat.c
- + rever.xsh
- setup.py
Changes:
=====================================
.authors.yml
=====================================
@@ -0,0 +1,67 @@
+- name: Aaron Meurer
+ email: asmeurer at gmail.com
+ github: asmeurer
+ num_commits: 1
+ first_commit: 2014-02-19 16:17:41
+- name: Jannis Leidel
+ email: jannis at leidel.info
+ github: jezdez
+ num_commits: 0
+ first_commit: 2022-06-28 05:35:02
+- name: Conda Bot
+ email: 18747875+conda-bot at users.noreply.github.com
+ github: conda-bot
+ aliases:
+ - conda-bot
+ - conda bot
+ alternate_emails:
+ - ad-team+condabot at anaconda.com
+ - conda-bot at users.noreply.github.com
+ - 18747875+conda-bot at users.noreply.github.com
+ num_commits: 22
+ first_commit: 2022-01-25 16:00:27
+- name: Ken Odegard
+ email: kodegard at anaconda.com
+ github: kenodegard
+ num_commits: 9
+ first_commit: 2022-06-15 14:15:32
+- name: Daniel Holth
+ email: dholth at anaconda.com
+ github: dholth
+ num_commits: 9
+ first_commit: 2022-10-14 14:44:28
+- name: Ilan Schnell
+ email: ilanschnell at gmail.com
+ github: ilanschnell
+ num_commits: 155
+ first_commit: 2013-03-23 22:44:55
+- name: William Schwartz
+ email: wkschwartz at gmail.com
+ github: wkschwartz
+ num_commits: 8
+ first_commit: 2013-11-04 15:35:43
+- name: Ray Donnelly
+ email: mingw.android at gmail.com
+ github: mingwandroid
+ num_commits: 2
+ first_commit: 2017-10-29 17:00:55
+- name: Bradley M. Froehle
+ email: brad.froehle at gmail.com
+ github: bfroehle
+ num_commits: 1
+ first_commit: 2013-05-27 18:40:21
+- name: Mike Sarahan
+ email: msarahan at gmail.com
+ github: msarahan
+ num_commits: 0
+ first_commit: 2017-10-30 19:02:20
+- name: Ondřej Čertík
+ email: ondrej.certik at gmail.com
+ github: certik
+ num_commits: 1
+ first_commit: 2013-03-28 21:20:51
+- name: Travis E. Oliphant
+ email: teoliphant at gmail.com
+ github: teoliphant
+ num_commits: 1
+ first_commit: 2013-03-26 00:19:31
=====================================
.github/ISSUE_TEMPLATE/0_bug.yml
=====================================
@@ -0,0 +1,78 @@
+---
+name: Bug Report
+description: Create a bug report.
+labels:
+ - type::bug
+body:
+ - type: markdown
+ attributes:
+ value: |
+ Because processing new bug reports is time-consuming, we would like to ask you to fill out the following form to the best of your ability and as completely as possible.
+
+ > **Note**
+ > Bug reports that are incomplete or missing information may be closed as inactionable.
+
+ Since there are already a lot of open issues, please also take a moment to search existing ones to see if your bug has already been reported. If you find something related, please upvote that issue and provide additional details as necessary.
+
+ 💐 Thank you for helping to make Conda better. We would be unable to improve Conda without our community!
+ - type: checkboxes
+ id: checks
+ attributes:
+ label: Checklist
+ description: Please confirm and check all of the following options.
+ options:
+ - label: I added a descriptive title
+ required: true
+ - label: I searched open reports and couldn't find a duplicate
+ required: true
+ - type: textarea
+ id: what
+ attributes:
+ label: What happened?
+ description: What should have happened instead? Please provide as many details as possible. The more information provided, the more likely we are able to replicate your problem and offer a solution.
+ validations:
+ required: true
+ - type: textarea
+ id: info
+ attributes:
+ label: Conda Info
+ description: |
+ Let's collect some basic information about your conda install.
+
+ Please run the following command from your command line and paste the output below.
+
+ ```bash
+ conda info
+ ```
+ render: shell
+ - type: textarea
+ id: config
+ attributes:
+ label: Conda Config
+ description: |
+ Let's collect any customizations you may have for your conda install.
+
+ Please run the following command from your command line and paste the output below.
+
+ ```bash
+ conda config --show-sources
+ ```
+ render: shell
+ - type: textarea
+ id: list
+ attributes:
+ label: Conda list
+ description: |
+ The packages installed into your environment can offer clues as to the problem you are facing.
+
+ Please activate the environment within which you are encountering this bug, run the following command from your command line, and paste the output below.
+
+ ```bash
+ conda list --show-channel-urls
+ ```
+ render: shell
+ - type: textarea
+ id: context
+ attributes:
+ label: Additional Context
+ description: Include any additional information (or screenshots) that you think would be valuable.
=====================================
.github/ISSUE_TEMPLATE/1_feature.yml
=====================================
@@ -0,0 +1,49 @@
+---
+name: Feature Request
+description: Create a feature request.
+labels:
+ - type::feature
+body:
+ - type: markdown
+ attributes:
+ value: |
+ Because processing new feature requests is time-consuming, we would like to ask you to fill out the following form to the best of your ability and as completely as possible.
+
+ > **Note**
+ > Feature requests that are incomplete or missing information may be closed as inactionable.
+
+ Since there are already a lot of open issues, please also take a moment to search existing ones to see if your feature request has already been submitted. If you find something related, please upvote that issue and provide additional details as necessary.
+
+ 💐 Thank you for helping to make Conda better. We would be unable to improve Conda without our community!
+ - type: checkboxes
+ id: checks
+ attributes:
+ label: Checklist
+ description: Please confirm and check all of the following options.
+ options:
+ - label: I added a descriptive title
+ required: true
+ - label: I searched open requests and couldn't find a duplicate
+ required: true
+ - type: textarea
+ id: idea
+ attributes:
+ label: What is the idea?
+ description: Describe what the feature is and the desired state.
+ validations:
+ required: true
+ - type: textarea
+ id: why
+ attributes:
+ label: Why is this needed?
+ description: Who would benefit from this feature? Why would this add value to them? What problem does this solve?
+ - type: textarea
+ id: what
+ attributes:
+ label: What should happen?
+ description: What should be the user experience with the feature? Describe from a user perpective what they would do and see.
+ - type: textarea
+ id: context
+ attributes:
+ label: Additional Context
+ description: Include any additional information that you think would be valuable.
=====================================
.github/ISSUE_TEMPLATE/epic.yml
=====================================
@@ -0,0 +1,47 @@
+---
+name: Epic
+description: A collection of related tickets.
+labels:
+ - epic
+body:
+ - type: markdown
+ attributes:
+ value: |
+ This form is intended for grouping and collecting together related tickets to better gauge the scope of a problem/feature.
+
+ If you are attempting to report a bug, propose a new feature, or some other code change please use one of the other forms available.
+
+ > **Note**
+ > Epics that are incomplete or missing information may be closed as inactionable.
+
+ Since there are already a lot of open issues, please also take a moment to search existing ones to see if a similar epic has already been opened. If you find something related, please upvote that issue and provide additional details as necessary.
+
+ 💐 Thank you for helping to make Conda better. We would be unable to improve Conda without our community!
+ - type: checkboxes
+ id: checks
+ attributes:
+ label: Checklist
+ description: Please confirm and check all of the following options.
+ options:
+ - label: I added a descriptive title
+ required: true
+ - label: I searched open reports and couldn't find a duplicate
+ required: true
+ - type: textarea
+ id: summary
+ attributes:
+ label: Summary
+ description: >-
+ Define the highlevel objectives to be accomplished in this epic. Include the
+ bigger picture of what is changing and/or the user story for why the
+ changes are desired/necessary.
+ validations:
+ required: true
+ - type: textarea
+ attributes:
+ label: Linked Issues & PRs
+ description: List all issues related to this epic.
+ value: |
+ - [ ] #
+ validations:
+ required: true
=====================================
.github/PULL_REQUEST_TEMPLATE.md
=====================================
@@ -0,0 +1,35 @@
+<!-- Hello! Thanks for submitting a PR! To help make things go a bit more
+ smoothly, we would appreciate it if you follow this template. -->
+
+### Description
+
+<!-- Good things to put here include:
+ - reasons for the change (please link any relevant issues!),
+ - any noteworthy (or hacky) choices to be aware of,
+ - or what the problem resolved here looked like. -->
+
+### Checklist - did you ...
+
+<!-- If any of the following items aren't relevant to your contribution,
+ please still tick them so we know you've gone through the checklist. -->
+
+- [ ] Add a file to the `news` directory ([using the template](../blob/main/news/TEMPLATE)) for the next release's release notes?
+ <!-- All "significant" changes should get an entry:
+ - user-facing changes or enhancements
+ - bug fixes
+ - deprecations
+ - documentation updates
+ - other changes -->
+- [ ] Add / update necessary tests?
+- [ ] Add / update outdated documentation?
+
+<!-- Just as a reminder, everyone in all conda org spaces (including PRs)
+ must follow the Conda Org Code of Conduct (link below).
+
+ Finally, once again, thanks for your time and effort. If you have any
+ feedback in regards to your experience contributing here, please
+ let us know!
+
+ Helpful links:
+ - Conda Org COC: https://github.com/conda-incubator/governance/blob/main/CODE_OF_CONDUCT.md
+ - Contributing docs: ../blob/main/CONTRIBUTING.md -->
=====================================
.github/workflows/cla.yml
=====================================
@@ -0,0 +1,36 @@
+---
+name: CLA
+
+on:
+ issue_comment:
+ types:
+ - created
+ pull_request_target:
+
+jobs:
+ check:
+ if: >-
+ !github.event.repository.fork
+ && (
+ github.event.issue.pull_request
+ && github.event.comment.body == '@conda-bot check'
+ || github.event_name == 'pull_request_target'
+ )
+ runs-on: ubuntu-latest
+ steps:
+ - name: Check CLA
+ uses: conda/actions/check-cla at v23.7.0
+ with:
+ # [required]
+ # A token with ability to comment, label, and modify the commit status
+ # (`pull_request: write` and `statuses: write` for fine-grained PAT; `repo` for classic PAT)
+ # (default: secrets.GITHUB_TOKEN)
+ token: ${{ secrets.CLA_ACTION_TOKEN }}
+ # [required]
+ # Label to apply to contributor's PR once CLA is signed
+ label: cla-signed
+
+ # [required]
+ # Token for opening singee PR in the provided `cla_repo`
+ # (`pull_request: write` for fine-grained PAT; `repo` and `workflow` for classic PAT)
+ cla_token: ${{ secrets.CLA_FORK_TOKEN }}
=====================================
.github/workflows/issues.yml
=====================================
@@ -0,0 +1,36 @@
+---
+name: Automate Issues
+
+on:
+ # NOTE: github.event is issue_comment payload:
+ # https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#issue_comment
+ issue_comment:
+ types: [created]
+
+env:
+ FEEDBACK_LBL: pending::feedback
+ SUPPORT_LBL: pending::support
+
+jobs:
+ # NOTE: will update label if anyone responds, not just the author/reporter
+ # TODO: create conda-issue-sorting team and modify this to toggle label based on
+ # whether a non-issue-sorting engineer commented
+ pending_support:
+ # if [pending::feedback] and anyone responds
+ if: >-
+ !github.event.repository.fork
+ && !github.event.issue.pull_request
+ && contains(github.event.issue.labels.*.name, 'pending::feedback')
+ runs-on: ubuntu-latest
+ steps:
+ # remove [pending::feedback]
+ - uses: actions-ecosystem/action-remove-labels at v1.3.0
+ with:
+ labels: ${{ env.FEEDBACK_LBL }}
+ github_token: ${{ secrets.PROJECT_TOKEN }}
+ # add [pending::support], if still open
+ - uses: actions-ecosystem/action-add-labels at v1.1.3
+ if: github.event.issue.state == 'open'
+ with:
+ labels: ${{ env.SUPPORT_LBL }}
+ github_token: ${{ secrets.PROJECT_TOKEN }}
=====================================
.github/workflows/labels.yml
=====================================
@@ -0,0 +1,43 @@
+---
+name: Sync Labels
+
+on:
+ # NOTE: github.event is workflow_dispatch payload:
+ # https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_dispatch
+ workflow_dispatch:
+ inputs:
+ dryrun:
+ description: 'dryrun: Preview changes to labels without editing them (true|false)'
+ required: true
+ type: boolean
+ default: true
+
+jobs:
+ sync:
+ if: '!github.event.repository.fork'
+ runs-on: ubuntu-latest
+ env:
+ GLOBAL: https://raw.githubusercontent.com/conda/infra/main/.github/global.yml
+ LOCAL: .github/labels.yml
+ steps:
+ - uses: actions/checkout at v4
+ - id: has_local
+ uses: andstor/file-existence-action at v2.0.0
+ with:
+ files: ${{ env.LOCAL }}
+ - name: Global Only
+ uses: EndBug/label-sync at v2.3.2
+ if: steps.has_local.outputs.files_exists == 'false'
+ with:
+ config-file: ${{ env.GLOBAL }}
+ delete-other-labels: true
+ dry-run: ${{ github.event.inputs.dryrun }}
+ - name: Global & Local
+ uses: EndBug/label-sync at v2.3.2
+ if: steps.has_local.outputs.files_exists == 'true'
+ with:
+ config-file: |
+ ${{ env.GLOBAL }}
+ ${{ env.LOCAL }}
+ delete-other-labels: true
+ dry-run: ${{ github.event.inputs.dryrun }}
=====================================
.github/workflows/lock.yml
=====================================
@@ -0,0 +1,46 @@
+---
+name: Lock
+
+on:
+ # NOTE: github.event is workflow_dispatch payload:
+ # https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_dispatch
+ workflow_dispatch:
+
+ schedule:
+ - cron: 0 6 * * *
+
+permissions:
+ issues: write
+ pull-requests: write
+
+jobs:
+ lock:
+ if: '!github.event.repository.fork'
+ runs-on: ubuntu-latest
+ steps:
+ - uses: dessant/lock-threads at v4
+ with:
+ # Number of days of inactivity before a closed issue is locked
+ issue-inactive-days: 365
+ # Do not lock issues created before a given timestamp, value must follow ISO 8601
+ exclude-issue-created-before: ''
+ # Do not lock issues with these labels, value must be a comma separated list of labels or ''
+ exclude-any-issue-labels: ''
+ # Labels to add before locking an issue, value must be a comma separated list of labels or ''
+ add-issue-labels: locked
+ # Reason for locking an issue, value must be one of resolved, off-topic, too heated, spam or ''
+ issue-lock-reason: resolved
+
+ # Number of days of inactivity before a closed pull request is locked
+ pr-inactive-days: 365
+ # Do not lock pull requests created before a given timestamp, value must follow ISO 8601
+ exclude-pr-created-before: ''
+ # Do not lock pull requests with these labels, value must be a comma separated list of labels or ''
+ exclude-any-pr-labels: ''
+ # Labels to add before locking a pull request, value must be a comma separated list of labels or ''
+ add-pr-labels: locked
+ # Reason for locking a pull request, value must be one of resolved, off-topic, too heated, spam or ''
+ pr-lock-reason: resolved
+
+ # Limit locking to only issues or pull requests, value must be one of issues, prs or ''
+ process-only: ''
=====================================
.github/workflows/project.yml
=====================================
@@ -0,0 +1,22 @@
+---
+name: Add to Project
+
+on:
+ issues:
+ types:
+ - opened
+ pull_request_target:
+ types:
+ - opened
+
+jobs:
+ add_to_project:
+ if: '!github.event.repository.fork'
+ runs-on: ubuntu-latest
+ steps:
+ - uses: actions/add-to-project at v0.5.0
+ with:
+ # issues are added to the Planning project
+ # PRs are added to the Review project
+ project-url: https://github.com/orgs/conda/projects/${{ github.event_name == 'issues' && 2 || 16 }}
+ github-token: ${{ secrets.PROJECT_TOKEN }}
=====================================
.github/workflows/stale.yml
=====================================
@@ -0,0 +1,99 @@
+---
+name: Stale
+
+on:
+ # NOTE: github.event is workflow_dispatch payload:
+ # https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_dispatch
+ workflow_dispatch:
+ inputs:
+ dryrun:
+ description: 'dryrun: Preview stale issues/prs without marking them (true|false)'
+ required: true
+ type: boolean
+ default: true
+
+ schedule:
+ - cron: 0 4 * * *
+
+permissions:
+ issues: write
+ pull-requests: write
+
+jobs:
+ stale:
+ if: '!github.event.repository.fork'
+ runs-on: ubuntu-latest
+ strategy:
+ matrix:
+ include:
+ - only-issue-labels: ''
+ days-before-issue-stale: 365
+ days-before-issue-close: 30
+ # [type::support] issues have a more aggressive stale/close timeline
+ - only-issue-labels: type::support
+ days-before-issue-stale: 90
+ days-before-issue-close: 21
+ steps:
+ - uses: conda/actions/read-yaml at v23.7.0
+ id: read_yaml
+ with:
+ path: https://raw.githubusercontent.com/conda/infra/main/.github/messages.yml
+
+ - uses: actions/stale at v8
+ id: stale
+ with:
+ # Only issues with these labels are checked whether they are stale
+ only-issue-labels: ${{ matrix.only-issue-labels }}
+
+ # Idle number of days before marking issues stale
+ days-before-issue-stale: ${{ matrix.days-before-issue-stale }}
+ # Idle number of days before closing stale issues/PRs
+ days-before-issue-close: ${{ matrix.days-before-issue-close }}
+ # Idle number of days before marking PRs stale
+ days-before-pr-stale: 365
+ # Idle number of days before closing stale PRs
+ days-before-pr-close: 30
+
+ # Comment on the staled issues
+ stale-issue-message: ${{ fromJSON(steps.read_yaml.outputs.value)['stale-issue'] }}
+ # Label to apply on staled issues
+ stale-issue-label: stale
+ # Label to apply on closed issues
+ close-issue-label: stale::closed
+ # Reason to use when closing issues
+ close-issue-reason: not_planned
+
+ # Comment on the staled PRs
+ stale-pr-message: ${{ fromJSON(steps.read_yaml.outputs.value)['stale-pr'] }}
+ # Label to apply on staled PRs
+ stale-pr-label: stale
+ # Label to apply on closed PRs
+ close-pr-label: stale::closed
+
+ # Remove stale label from issues/PRs on updates/comments
+ remove-stale-when-updated: true
+ # Add specified labels to issues/PRs when they become unstale
+ labels-to-add-when-unstale: stale::recovered
+ # Remove specified labels to issues/PRs when they become unstale
+ labels-to-remove-when-unstale: stale,stale::closed
+
+ # Max number of operations per run
+ operations-per-run: ${{ secrets.STALE_OPERATIONS_PER_RUN || 100 }}
+ # Dry-run
+ debug-only: ${{ github.event.inputs.dryrun || false }}
+ # Order to get issues/PRs
+ ascending: true
+ # Delete branch after closing a stale PR
+ delete-branch: false
+
+ # Issues with these labels will never be considered stale
+ exempt-issue-labels: stale::recovered,epic
+ # Issues with these labels will never be considered stale
+ exempt-pr-labels: stale::recovered,epic
+ # Exempt all issues/PRs with milestones from stale
+ exempt-all-milestones: true
+ # Assignees on issues/PRs exempted from stale
+ exempt-assignees: mingwandroid
+
+ - name: Print outputs
+ run: echo ${{ join(steps.stale.outputs.*, ',') }}
=====================================
.gitignore
=====================================
@@ -7,3 +7,4 @@
build/
dist/
__pycache__/
+rever/
=====================================
.mailmap
=====================================
@@ -0,0 +1,28 @@
+# This file was autogenerated by rever: https://regro.github.io/rever-docs/
+# This prevent git from showing duplicates with various logging commands.
+# See the git documentation for more details. The syntax is:
+#
+# good-name <good-email> bad-name <bad-email>
+#
+# You can skip bad-name if it is the same as good-name and is unique in the repo.
+#
+# This file is up-to-date if the command git log --format="%aN <%aE>" | sort -u
+# gives no duplicates.
+
+Aaron Meurer <asmeurer at gmail.com>
+Bradley M. Froehle <brad.froehle at gmail.com>
+Conda Bot <18747875+conda-bot at users.noreply.github.com> conda-bot <ad-team+condabot at anaconda.com>
+Conda Bot <18747875+conda-bot at users.noreply.github.com> conda-bot <conda-bot at users.noreply.github.com>
+Conda Bot <18747875+conda-bot at users.noreply.github.com> conda-bot <18747875+conda-bot at users.noreply.github.com>
+Conda Bot <18747875+conda-bot at users.noreply.github.com> conda bot <ad-team+condabot at anaconda.com>
+Conda Bot <18747875+conda-bot at users.noreply.github.com> conda bot <conda-bot at users.noreply.github.com>
+Conda Bot <18747875+conda-bot at users.noreply.github.com> conda bot <18747875+conda-bot at users.noreply.github.com>
+Daniel Holth <dholth at anaconda.com>
+Ilan Schnell <ilanschnell at gmail.com>
+Jannis Leidel <jannis at leidel.info>
+Ken Odegard <kodegard at anaconda.com>
+Mike Sarahan <msarahan at gmail.com>
+Ondřej Čertík <ondrej.certik at gmail.com>
+Ray Donnelly <mingw.android at gmail.com>
+Travis E. Oliphant <teoliphant at gmail.com>
+William Schwartz <wkschwartz at gmail.com>
=====================================
AUTHORS.md
=====================================
@@ -0,0 +1,15 @@
+All of the people who have made at least one contribution to pycosat.
+Authors are sorted alphabetically.
+
+* Aaron Meurer
+* Bradley M. Froehle
+* Conda Bot
+* Daniel Holth
+* Ilan Schnell
+* Jannis Leidel
+* Ken Odegard
+* Mike Sarahan
+* Ondřej Čertík
+* Ray Donnelly
+* Travis E. Oliphant
+* William Schwartz
=====================================
CHANGELOG deleted
=====================================
@@ -1,79 +0,0 @@
-2022-10-24 0.6.4:
--------------------
- * Fix memory leak in blocksol() when iterating over solutions
-
-
-2017-10-29 0.6.3:
--------------------
- * Revert 'always use Python memory manager'
-
-
-2017-03-16 0.6.2:
--------------------
- * update picosat to 965
- * fixed __version__ attribute on Windows, #21
- * fix some typos
- * add official Python 3.5 and 3.6 support
-
-
-2014-04-28 0.6.1:
--------------------
- * fix the initialization of the soliterator type in Py3k, thanks bfroehle
- * update picosat from 954 to 957
- * add ability of solve and itersolve to take general iterables as clauses
- arguments, each containing general iterables
-
-
-2013-04-16 0.6.0:
--------------------
- * add ability to specify clauses as objects which support the iterator
- protocol
- * added a Python 3 version of the 8 queens example which demonstrates
- the usefulness of the "yield from" statement
-
-
-2013-04-09 0.5.0:
--------------------
- * add Python 2.5 support
- * add module docstring
- * add 8 queens problem as an example
-
-
-2013-04-01 0.4.2:
--------------------
- * fixed types in readme
- * add SAT-based Sudoku solver as an example
- * add docstings to solve and itersolve
- * add test for clauses containing type long literals on Python 2
-
-
-2013-03-28 0.4.1:
--------------------
- * add documentation
- * added more tests
- * add error handling for memory management
-
-
-2013-03-27 0.4.0:
--------------------
- * allow keyword arguments to pycosat.solve and pycosat.itersolve
- * add ability to set propagation limit
- * fixed some bugs which were causing segfaults
-
-
-2013-03-26 0.3.0:
--------------------
- * add solution iterator (pycosat.itersolve)
- * make number of variables optional argument
-
-
-2013-03-25 0.2.0:
--------------------
- * fixed MSVC compiler problems
- * use Python memory manager in picosat
- * release GIL during main picosat computation
-
-
-2013-03-24 0.1.0:
--------------------
- * initial pre-alpha release
=====================================
CHANGELOG.md
=====================================
@@ -0,0 +1,109 @@
+[//]: # (current developments)
+
+## 0.6.6 (2023-10-03)
+
+### Bug fixes
+
+* Fix `PyMem_Calloc()` call signature. (#76)
+
+### Contributors
+
+* @dholth
+* @kenodegard
+
+
+
+## 0.6.5 (2023-10-02)
+
+### Enhancements
+
+* Update Python version support. (#56)
+
+### Bug fixes
+
+* Use `PyMem_Calloc()` to initialize memory to `0`. (#58)
+
+### Contributors
+
+* @conda-bot
+* @dholth made their first contribution in https://github.com/conda/pycosat/pull/54
+* @kenodegard
+
+
+
+## 0.6.4 (2022-10-24)
+
+* Fix memory leak in blocksol() when iterating over solutions
+
+
+## 0.6.3 (2017-10-29)
+
+* Revert 'always use Python memory manager'
+
+
+## 0.6.2 (2017-03-16)
+
+* update picosat to 965
+* fixed __version__ attribute on Windows, #21
+* fix some typos
+* add official Python 3.5 and 3.6 support
+
+
+## 0.6.1 (2014-04-28)
+
+* fix the initialization of the soliterator type in Py3k, thanks bfroehle
+* update picosat from 954 to 957
+* add ability of solve and itersolve to take general iterables as clauses arguments, each containing general iterables
+
+
+## 0.6.0 (2013-04-16)
+
+* add ability to specify clauses as objects which support the iterator protocol
+* added a Python 3 version of the 8 queens example which demonstrates the usefulness of the "yield from" statement
+
+
+## 0.5.0 (2013-04-09)
+
+* add Python 2.5 support
+* add module docstring
+* add 8 queens problem as an example
+
+
+## 0.4.2 (2013-04-01)
+
+* fixed types in readme
+* add SAT-based Sudoku solver as an example
+* add docstings to solve and itersolve
+* add test for clauses containing type long literals on Python 2
+
+
+## 0.4.1 (2013-03-28)
+
+* add documentation
+* added more tests
+* add error handling for memory management
+
+
+## 0.4.0 (2013-03-27)
+
+* allow keyword arguments to pycosat.solve and pycosat.itersolve
+* add ability to set propagation limit
+* fixed some bugs which were causing segfaults
+
+
+## 0.3.0 (2013-03-26)
+
+* add solution iterator (pycosat.itersolve)
+* make number of variables optional argument
+
+
+## 0.2.0 (2013-03-25)
+
+* fixed MSVC compiler problems
+* use Python memory manager in picosat
+* release GIL during main picosat computation
+
+
+## 0.1.0 (2013-03-24)
+
+* initial pre-alpha release
=====================================
CODE_OF_CONDUCT.md
=====================================
@@ -1,3 +1,20 @@
-# Code of Conduct
+# Conda Organization Code of Conduct
-This repo adheres to the [NumFOCUS Code of Conduct](https://www.numfocus.org/code-of-conduct).
+> **Note**
+> Below is the short version of our CoC, see the long version [here](https://github.com/conda-incubator/governance/blob/main/CODE_OF_CONDUCT.md).
+
+# The Short Version
+
+Be kind to others. Do not insult or put down others. Behave professionally. Remember that harassment and sexist, racist, or exclusionary jokes are not appropriate for the conda Organization.
+
+All communication should be appropriate for a professional audience including people of many different backgrounds. Sexual language and imagery is not appropriate.
+
+The conda Organization is dedicated to providing a harassment-free community for everyone, regardless of gender, sexual orientation, gender identity and expression, disability, physical appearance, body size, race, or religion. We do not tolerate harassment of community members in any form.
+
+Thank you for helping make this a welcoming, friendly community for all.
+
+## Report an Incident
+
+* Report a code of conduct incident [using a form](https://form.jotform.com/221527028480048).
+* Report a code of conduct incident via email: [conduct at conda.org](mailto:conduct at conda.org).
+* Contact [an individual committee member](#committee-membership) or [CoC event representative](#coc-representatives) to report an incident in confidence.
=====================================
HOW_WE_USE_GITHUB.md
=====================================
@@ -6,42 +6,52 @@
[project-sorting]: https://github.com/orgs/conda/projects/2/views/11
[project-support]: https://github.com/orgs/conda/projects/2/views/12
[project-backlog]: https://github.com/orgs/conda/projects/2/views/13
-[project-sprint]: https://github.com/orgs/conda/projects/2/views/14
+[project-in-progress]: https://github.com/orgs/conda/projects/2/views/14
[docs-toc]: https://github.blog/changelog/2021-04-13-table-of-contents-support-in-markdown-files/
[docs-actions]: https://docs.github.com/en/actions
[docs-saved-reply]: https://docs.github.com/en/get-started/writing-on-github/working-with-saved-replies/creating-a-saved-reply
+[docs-commit-signing]: https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits
-[workflow-sync]: https://github.com/conda/infra/blob/main/.github/workflows/sync.yml
-[labels-global]: https://github.com/conda/infra/blob/main/.github/global.yml
+[infrastructure]: https://github.com/conda/infrastructure
+[workflow-sync]: https://github.com/conda/infrastructure/blob/main/.github/workflows/sync.yml
+[labels-global]: https://github.com/conda/infrastructure/blob/main/.github/global.yml
<!-- relative URLs -->
+[workflow-cla]: /.github/workflows/cla.yml
[workflow-issues]: /.github/workflows/issues.yml
+[workflow-labels]: /.github/workflows/labels.yml
+[workflow-lock]: /.github/workflows/lock.yml
[workflow-project]: /.github/workflows/project.yml
+[workflow-stale]: /.github/workflows/stale.yml
[labels-local]: /.github/labels.yml
+[labels-page]: ../../labels
-## How We Use GitHub
+# How We Use GitHub
-> **Note**
-> For easy navigation use [GitHub's table of contents feature][docs-toc].
-
-This document seeks to outline how we as a community use GitHub Issues to track bugs and feature requests while still catering to development practices & project management (*e.g.*, release cycles, feature planning, priority sorting, etc.).
+This document seeks to outline how we as a community use GitHub Issues to track bugs and feature requests while still catering to development practices & project management (_e.g._, release cycles, feature planning, priority sorting, etc.).
<!-- only include high-level topics or particularly noteworthy sections here -->
-Topics:
- - [What is Issue Sorting?](#what-is-issue-sorting)
- - [Types of tickets](#types-of-tickets)
- - [Normal Ticket/Issue](#normal-ticketissue)
+**Topics:**
+
+ - [What is "Issue Sorting"?](#what-is-issue-sorting)
+ - [Issue Sorting Procedures](#issue-sorting-procedures)
+ - [Commit Signing](#commit-signing)
+ - [Types of Issues](#types-of-issues)
+ - [Standard Issue](#standard-issue)
- [Epics](#epics)
- [Spikes](#spikes)
+ - [Working on Issues](#working-on-issues)
+> **Note**
+> This document is written in the style of an FAQ. For easier navigation, use [GitHub's table of contents feature][docs-toc].
-### What is "Issue Sorting"?
+## What is "Issue Sorting"?
> **Note**
-> "Issue sorting" is similar to that of "triaging", but we've chosen to use different terminology because "triaging" is a word related to very weighty topics (*e.g.*, injuries and war) and we would like to be sensitive to those connotations. Additionally, we are taking a more "fuzzy" approach to sorting (*e.g.*, severities may not be assigned, etc.).
+> "Issue sorting" is similar to that of "triaging", but we've chosen to use different terminology because "triaging" is a word related to very weighty topics (_e.g._, injuries and war) and we would like to be sensitive to those connotations. Additionally, we are taking a more "fuzzy" approach to sorting (_e.g._, severities may not be assigned, etc.).
-"Issue Sorting" refers to the process of assessing the priority of incoming issues. Below is a high-level diagram of the flow of tickets:
+"Issue Sorting" refers to the process of assessing the priority of incoming issues. Below is a high-level diagram of the flow of issues:
```mermaid
flowchart LR
@@ -58,8 +68,8 @@ flowchart LR
board_backlog-- refine -->board_backlog
end
- subgraph flow_sprint [Sprint]
- board_sprint{{Sprint}}
+ subgraph flow_progress [In Progress]
+ board_progress{{In Progress}}
end
state_new(New Issues)
@@ -69,15 +79,12 @@ flowchart LR
board_sorting-- investigated -->board_backlog
board_sorting-- duplicates, off-topic -->state_closed
board_support-- resolved, unresponsive -->state_closed
- board_backlog-- pending work -->board_sprint
+ board_backlog-- pending work -->board_progress
board_backlog-- resolved, irrelevant -->state_closed
- board_sprint-- resolved -->state_closed
+ board_progress-- resolved -->state_closed
```
-In order to explain how various `conda` issues are evaluated, the following document will provide information about our sorting process in the form of an FAQ.
-
-
-#### Why sort issues?
+### Why sort issues?
At the most basic "bird's eye view" level, sorted issues will fall into the category of four main priority levels:
@@ -88,113 +95,133 @@ At the most basic "bird's eye view" level, sorted issues will fall into the cate
At its core, sorting enables new issues to be placed into these four categories, which helps to ensure that they will be processed at a velocity similar to or exceeding the rate at which new issues are coming in. One of the benefits of actively sorting issues is to avoid engineer burnout and to make necessary work sustainable; this is done by eliminating a never-ending backlog that has not been reviewed by any maintainers.
-There will always be broad-scope design and architecture implementations that the `conda` maintainers will be interested in pursuing; by actively organizing issues, the sorting engineers will be able to more easily track and tackle both specific and big-picture goals.
+There will always be broad-scope design and architecture implementations that the maintainers will be interested in pursuing; by actively organizing issues, the sorting engineers will be able to more easily track and tackle both specific and big-picture goals.
-#### Who does the sorting?
+### Who does the sorting?
-Sorting engineers are a `conda` governance [sub-team][sub-team]; they are a group of Anaconda and community members who are responsible for making decisions regarding closing issues and setting feature work priorities, amongst other sorting-related tasks.
+Sorting engineers are a conda governance [sub-team][sub-team]; they are a group of community members who are responsible for making decisions regarding closing issues and setting feature work priorities, among other sorting-related tasks.
+### How do items show up for sorting?
-#### How do items show up for sorting?
+New issues that are opened in any of the repositories in the [conda GitHub organization][conda-org] will show up in the "Sorting" tab of the [Planning project][project-planning]. There are two [GitHub Actions][docs-actions] workflows utilized for this purpose; [`.github/workflows/issues.yml`][workflow-issues] and [`.github/workflows/project.yml`][workflow-project].
-New issues that are opened in any of the repositories in the [`conda` GitHub project][conda-org] will show up in the `Sorting` view of the [Planning project][project-planning]. This process is executed via [GitHub Actions][docs-actions]. The two main GitHub Actions workflows utilized for this purpose are [Issues][workflow-issues] and [Project][workflow-project].
+The GitHub Actions in the [`conda/infrastructure`][infrastructure] repository are viewed as canonical; the [`.github/workflows/sync.yml` workflow][workflow-sync] sends out any modifications to other `conda` repositories from there.
-The GitHub Actions in the `conda/infra` repository are viewed as canonical; the [Sync workflow][workflow-sync] sends out any modifications to other `conda` repositories from there.
+### What is done about the issues in the "Sorting" tab?
-
-#### What is done about the issues in "sorting" mode?
-
-Issues in the ["Sorting" tab of the project board][project-sorting] have been reviewed by a sorting engineer and are considered ready for the following procedures:
+Issues in the ["Sorting" tab of the project board][project-sorting] are considered ready for the following procedures:
- Mitigation via short-term workarounds and fixes
- Redirection to the correct project
- Determining if support can be provided for errors and questions
- Closing out of any duplicate/off-topic issues
-The sorting engineers on rotation are not seeking to _resolve_ issues that arise. Instead, the goal is to understand the ticket and to determine whether it is an issue in the first place, and then to collect as much relevant information as possible so that the maintainers of `conda` can make an informed decision about the appropriate resolution schedule.
+The sorting engineers on rotation are not seeking to _resolve_ issues that arise. Instead, the goal is to understand the issue and to determine whether it is legitimate, and then to collect as much relevant information as possible so that the maintainers can make an informed decision about the appropriate resolution schedule.
-Issues will remain in the "Sorting" tab as long as the issue is in an investigatory phase (_e.g._, querying the user for more details, asking the user to attempt other workarounds, other debugging efforts, etc.) and are likely to remain in this state the longest, but should still be progressing over the course of 1-2 weeks.
+Issues will remain in the ["Sorting" tab][project-sorting] as long as the issue is in an investigatory phase (_e.g._, querying the user for more details, asking the user to attempt other workarounds, other debugging efforts, etc.) and are likely to remain in this state the longest, but should still be progressing over the course of 1-2 weeks.
+For more information on the sorting process, see [Issue Sorting Procedures](#issue-sorting-procedures).
-#### When do items move out of the "Sorting" tab?
+### When do items move out of the "Sorting" tab?
-The additional tabs in the project board that the issues can be moved to include the following:
+Items move out of the ["Sorting" tab][project-sorting] once the investigatory phase described in [What is done about the issues in the "Sorting" tab?](#what-is-done-about-the-issues-in-the-sorting-tab) has concluded and the sorting engineer has enough information to make a decision about the appropriate resolution schedule for the issue. The additional tabs in the project board that the issues can be moved to include the following:
-- **"Support"** - Any issue in the ["Support" tab of the Planning board][project-support] is a request for support and is not a feature request or a bug report. All issues considered "support" should include the https://github.com/conda/infra/labels/type%3A%3Asupport label.
-- **"Backlog"** - The issue has revealed a bug or feature request. We have collected enough details to understand the problem/request and to reproduce it on our own. These issues have been moved into the [Backlog tab of the Planning board][project-backlog] at the end of the sorting rotation during Refinement.
+- **"Support"** - Any issue in the ["Support" tab of the Planning board][project-support] is a request for support and is not a feature request or a bug report. Add the [`type::support`](https://github.com/conda/infrastructure/labels/type%3A%3Asupport) label to move an issue to this tab.
+- **"Backlog"** - The issue has revealed a bug or feature request. We have collected enough details to understand the problem/request and to reproduce it on our own. These issues have been moved into the [Backlog tab of the Planning board][project-backlog] at the end of the sorting rotation during Refinement. Add the [`backlog`](https://github.com/conda/infrastructure/labels/backlog) label to move an issue to this tab.
- **"Closed"** - The issue was closed due to being a duplicate, being redirected to a different project, was a user error, a question that has been resolved, etc.
+### Where do work issues go after being sorted?
-#### Where do items go after being sorted?
+Once issues are deemed ready to be worked on, they will be moved to the ["Backlog" tab of the Planning board][project-backlog]. Once actively in progress, the issues will be moved to the ["In Progress" tab of the Planning board][project-in-progress] and then closed out once the work is complete.
-All sorted issues will be reviewed by sorting engineers during a weekly Refinement meeting in order to understand how those particular issues fit into the short- and long-term roadmap of `conda`. These meetings enable the sorting engineers to get together to collectively prioritize issues, earmark feature requests for specific future releases (versus a more open-ended backlog), tag issues as ideal for first-time contributors, as well as whether or not to close/reject specific feature requests.
+### What is the purpose of having a "Backlog"?
-Once issues are deemed ready to be worked on, they will be moved to the [`conda` Backlog tab of the Planning board][project-backlog] on GitHub. Once actively in progress, the issues will be moved to the [Sprint tab of the Planning board][project-sprint] and then closed out once the work is complete.
+Issues are "backlogged" when they have been sorted but not yet earmarked for an upcoming release.
+### What automation procedures are currently in place?
-#### What is the purpose of having a "Backlog"?
+Global automation procedures synced out from the [`conda/infrastructure`][infrastructure] repo include:
-Issues are "backlogged" when they have been sorted but not yet earmarked for an upcoming release. Weekly Refinement meetings are a time when the `conda` engineers will transition issues from "[Sorting][project-sorting]" to "[Backlog][project-backlog]". Additionally, this time of handoff will include discussions around the kind of issues that were raised, which provides an opportunity to identify any patterns that may point to a larger problem.
+- [Marking of issues and pull requests as stale][workflow-stale], resulting in:
+ - issues marked as [`type::support`](https://github.com/conda/infrastructure/labels/type%3A%3Asupport) being labeled stale after 21 days of inactivity and being closed after 7 further days of inactivity (that is, closed after 30 inactive days total)
+ - all other inactive issues (not labeled as [`type::support`](https://github.com/conda/infrastructure/labels/type%3A%3Asupport) being labeled stale after 365 days of inactivity and being closed after 30 further days of inactivity (that is, closed after an approximate total of 1 year and 1 month of inactivity)
+ - all inactive pull requests being labeled stale after 365 days of inactivity and being closed after 30 further days of inactivity (that is, closed after an approximate total of 1 year and 1 month of inactivity)
+- [Locking of closed issues and pull requests with no further activity][workflow-lock] after 365 days
+- [Adding new issues and pull requests to the respective project boards][workflow-project]
+- [Indicating an issue is ready for the sorting engineer's attention][workflow-issues] by toggling [`pending::feedback`](https://github.com/conda/infrastructure/labels/pending%3A%3Afeedback) with [`pending::support`](https://github.com/conda/infrastructure/labels/pending%3A%3Asupport) after a contributor leaves a comment
+- [Verifying that contributors have signed the CLA][workflow-cla] before allowing pull requests to be merged; if the contributor hasn't signed the CLA previously, merging is be blocked until a manual review can be done
+- [Syncing out templates, labels, workflows, and documentation][workflow-sync] from [`conda/infrastructure`][infrastructure] to the other repositories
+## Issue Sorting Procedures
-#### What is the purpose of a "development sprint"?
+### How are issues sorted?
-After issues have been sorted and backlogged, they will eventually be moved into the "Sprint Candidate", "Short-Term", "Medium-Term", "Long-Term", or "No Time Frame" sections of the [Backlog tab of the Planning board][project-backlog] and get one or more sprint cycles dedicated to them.
+Issues in the ["Sorting" tab of the Planning board][project-sorting] are reviewed by issue sorting engineers, who take rotational sorting shifts. In the process of sorting issues, engineers label the issues and move them to the other tabs of the project board for further action.
-The purpose of a development sprint is to enable a steady delivery of enhancements, features, and bug fixes by setting aside pre-determined portions of time that are meant for focusing on specifically-assigned items.
+Issues that require input from multiple members of the sorting team will be brought up during refinement meetings in order to understand how those particular issues fit into the short- and long-term roadmap. These meetings enable the sorting engineers to get together to collectively prioritize issues, earmark feature requests for specific future releases (versus a more open-ended backlog), tag issues as ideal for first-time contributors, as well as whether or not to close/reject specific feature requests.
-Sprints also serve to focus the engineering team's attention on more accurate planning for what is to come during the entire release cycle, as well as keep the scope of development work concise. They enable the setting aside of dedicated time for the engineers to resolve any problems with the work involved, instead of pushing these problems to the end of the release cycle when there may not be any time remaining to fix issues.
+### How does labeling work?
+Labeling is a very important means for sorting engineers to keep track of the current state of an issue with regards to the asynchronous nature of communicating with users. Utilizing the proper labels helps to identify the severity of the issue as well as to quickly understand the current state of a discussion.
-#### How does labeling work?
+Each label has an associated description that clarifies how the label should be used. Hover on the label to see its description. Label colors are used to distinguish labels by category.
-Labeling is a very important means for sorting engineers to keep track of the current state of an issue with regards to the asynchronous nature of communicating with users. Utilizing the proper labels helps to identify the severity of the issue as well as to quickly understand the current state of a discussion.
+Generally speaking, labels with the same category are considered mutually exclusive, but in some cases labels sharing the same category can occur concurrently, as they indicate qualifiers as opposed to types. For example, we may have the following types, [`type::bug`](https://github.com/conda/infrastructure/labels/type%3A%3Abug), [`type::feature`](https://github.com/conda/infrastructure/labels/type%3A%3Afeature), and [`type::documentation`](https://github.com/conda/infrastructure/labels/type%3A%3Adocumentation), where for any one issue there would be _at most_ **one** of these to be defined (_i.e._ an issue should not be a bug _and_ a feature request at the same time). Alternatively, with issues involving specific operating systems (_i.e._, [`os::linux`](https://github.com/conda/infrastructure/labels/os%3A%3Alinux), [`os::macos`](https://github.com/conda/infrastructure/labels/os%3A%3Amacos), and [`os::windows`](https://github.com/conda/infrastructure/labels/os%3A%3Awindows)), an issue could be labeled with one or more, depending on the system(s) the issue occurs on.
+
+Please note that there are also automation policies in place that are affected by labeling. For example, if an issue is labeled as [`type::support`](https://github.com/conda/infrastructure/labels/type%3A%3Asupport), that issue will be marked [`stale`](https://github.com/conda/infrastructure/labels/stale) after 21 days of inactivity and auto-closed after seven more days without activity (30 inactive days total), which is earlier than issues without this label. See [What automation procedures are currently in place?](#what-automation-procedures-are-currently-in-place) for more details.
-Generally speaking, labels with the same category are considered mutually exclusive but in some cases labels sharing the same category can occur concurrently as they indicate qualifiers as opposed to types. For example, we may have the following types, https://github.com/conda/infra/labels/type%3A%3Abug, https://github.com/conda/infra/labels/type%3A%3Afeature, and https://github.com/conda/infra/labels/type%3A%3Adocumentation, where for any one issue there would be _at most_ **one** of these to be defined (_i.e._ an issue shouldn’t be a bug _and_ a feature request at the same time). Alternatively, with issues involving specific operating systems (_i.e._, https://github.com/conda/infra/labels/os%3A%3Alinux, https://github.com/conda/infra/labels/os%3A%3Amacos, and https://github.com/conda/infra/labels/os%3A%3Awindows), an issue could be labeled with one or more depending on the system(s) the issue is occurring on.
+### What labels are required for each issue?
-Please note that there are also automation policies in place. For example, if an issue is labeled as https://github.com/conda/infra/labels/pending%3A%3Afeedback and https://github.com/conda/infra/labels/unreproducible, that issue will be auto-closed after a month of inactivity.
+At minimum, both `type` and `source` labels should be specified on each issue before moving it from the "Sorting" tab to the "Backlog" tab. All issues that are bugs should also be tagged with a `severity` label.
+The `type` labels are exclusive of each other: each sorted issue should have exactly one `type` label. These labels give high-level information on the issue's classification (_e.g._, bug, feature, tech debt, etc.)
-#### How are new labels defined?
+The `source` labels are exclusive of each other: each sorted issue should have exactly one `source` label. These labels give information on the sub-group to which the issue's author belongs (_e.g._, a partner, a frequent contributor, the wider community, etc.). Through these labels, maintainers gain insight into how well we're meeting the needs of various groups.
-Labels are defined using a scoped syntax with an optional high-level category (_e.g._, source, tag, type, etc.) and a specific topic, much like the following:
+The `severity` labels are exclusive of each other and, while required for the [`type::bug`](https://github.com/conda/infrastructure/labels/type%3A%bug) label, they can also be applied to other types to indicate demand or need. These labels help us to prioritize our work. Severity is not the only factor for work prioritization, but it is an important consideration.
+
+Please review the descriptions of the `type`, `source`, and `severity` labels on the [labels page][labels-page] prior to use.
+
+### How are new labels defined?
+
+Labels are defined using a scoped syntax with an optional high-level category (_e.g._, `source`, `tag`, `type`, etc.) and a specific topic, much like the following:
- `[topic]`
- `[category::topic]`
- `[category::topic-phrase]`
-This syntax helps with issue sorting enforcement; at minimum, both `type` and `source` labels should be specified on each issue before moving it from "`Sorting`" to "`Backlog`".
+This syntax helps with issue sorting enforcement, as it helps to ensure that sorted issues are, at minimum, categorized by type and source.
-There are a number of labels that have been defined for the different `conda` projects. In order to create a streamlined sorting process, label terminologies are standardized using similar (if not the same) labels.
+There are a number of labels that have been defined for the different repositories. In order to create a streamlined sorting process, label terminologies are standardized using similar (if not the same) labels.
+### How are new labels added?
-#### How are new labels added?
+New **global** labels (_i.e._, labels that apply equally to all repositories within the conda GitHub organization) are added to [`conda/infrastructure`][infrastructure]'s [`.github/global.yml` file][labels-global]; new **local** labels (_i.e._, labels specific to particular repositories) are added to each repository's [`.github/labels.yml` file][labels-local]. All new labels should follow the labeling syntax described in ["How are new labels defined?"](#how-are-new-labels-defined). Global labels are combined with any local labels and these aggregated labels are used by the [`.github/workflows/labels.yml` workflow][workflow-labels] to synchronize the labels available for the repository.
-New **global** labels (_i.e._, generic labels that apply equally to all `conda` repos) can be added to the `conda/infra`'s [`.github/global.yml` file][labels-global]; new **local** labels (_i.e._, labels specific to particular `conda` repos) can be added to each repository's [`.github/labels.yml`][labels-local] file. All new labels should follow the labeling syntax described in the "How are new labels defined?" section of this document.
+### Are there any templates to use as responses for commonly-seen issues?
-
-#### Are there any templates to use as responses for commonly-seen issues?
-
-Some of the same types of issues appear regularly (_e.g._, issues that are duplicates of others, tickets that should be filed in the Anaconda issue tracker, errors that are due to a user's specific setup/environment, etc.).
+Some of the same types of issues appear regularly (_e.g._, issues that are duplicates of others, issues that should be filed in the Anaconda issue tracker, errors that are due to a user's specific setup/environment, etc.).
Below are some boilerplate responses for the most commonly-seen issues to be sorted:
<details>
<summary><b>Duplicate Issue</b></summary>
+<!-- this is a code block, any links need to be embedded -->
<pre>
This is a duplicate of <b>[link to primary issue]</b>; please feel free to continue the discussion there.
</pre>
> **Warning**
-> Apply the https://github.com/conda/infra/labels/duplicate label to the issue being closed and https://github.com/conda/infra/labels/duplicate%3A%3Aprimary to the original issue.
+> Apply the https://github.com/conda/infrastructure/labels/duplicate label to the issue being closed and https://github.com/conda/infrastructure/labels/duplicate%3A%3Aprimary to the original issue.
</details>
<details>
<summary><b>Requesting an Uninstall/Reinstall of <code>conda</code></b></summary>
+<!-- this is a code block, any links need to be embedded -->
<pre>
Please uninstall your current version of `conda` and reinstall the latest version.
@@ -208,6 +235,7 @@ whichever is more appropriate for your needs.
<details>
<summary><b>Redirect to Anaconda Issue Tracker</b></summary>
+<!-- this is a code block, any links need to be embedded -->
<pre>
Thank you for filing this issue! Unfortunately, this is off-topic for this repo.
@@ -217,13 +245,14 @@ where `conda` installer/package issues are addressed.
</pre>
> **Warning**
-> Apply the https://github.com/conda/infra/labels/off-topic label to these tickets before closing them out.
+> Apply the https://github.com/conda/infrastructure/labels/off-topic label to these issues before closing them out.
</details>
<details>
<summary><b>Redirecting to Nucleus Forums</b></summary>
+<!-- this is a code block, any links need to be embedded -->
<pre>
Unfortunately, this issue is outside the scope of support we offer via GitHub;
@@ -232,23 +261,74 @@ please post details to the [Nucleus forums](https://community.anaconda.cloud/).
</pre>
> **Warning**
-> Apply the https://github.com/conda/infra/labels/off-topic label to these tickets before closing them out.
+> Apply the https://github.com/conda/infrastructure/labels/off-topic label to these issues before closing them out.
</details>
-In order to not have to manually type or copy/paste the above repeatedly, please note that it's possible to add text for the most commonly-used responses via [GitHub's "Add Saved Reply" option][docs-saved-reply].
+<details>
+<summary><b>Slow solving of conda environment</b></summary>
+<!-- this is a code block, any links need to be embedded -->
+<pre>
+Hi [@username],
-### Types of Tickets
+Thanks for voicing your concern about the performance of the classic dependency solver. To fix this, our official recommendation is using the new default "conda-libmamba-solver" instead of the classic solver (more information about the "conda-libmamba-solver" can be found here: https://conda.github.io/conda-libmamba-solver/getting-started/).
-#### Standard Ticket/Issue
+In most cases "conda-libmamba-solver" should be significantly faster than the "classic" solver. We hope it provides you with a much better experience going forward.
+</pre>
+
+</details>
-TODO
-#### Epics
+In order to not have to manually type or copy/paste the above repeatedly, note that it's possible to add text for the most commonly-used responses via [GitHub's "Add Saved Reply" option][docs-saved-reply].
+
+## Commit Signing
+
+For all conda maintainers, we require commit signing and strongly recommend it for all others wishing to contribute to conda
+related projects. More information about how to set this up within GitHub can be found here:
+
+- [GitHub's signing commits docs][docs-commit-signing]
+
+## Types of Issues
+
+### Standard Issue
TODO
-#### Spikes
+### Epics
TODO
+
+### Spikes
+
+#### What is a spike?
+
+"Spike" is a term that is borrowed from extreme programming and agile development. They are used when the **outcome of an issue is unknown or even optional**. For example, when first coming across a problem that has not been solved before, a project may choose to either research the problem or create a prototype in order to better understand it.
+
+Additionally, spikes represent work that **may or may not actually be completed or implemented**. An example of this are prototypes created to explore possible solutions. Not all prototypes are implemented and the purpose of creating a prototype is often to explore the problem space more. For research-oriented tasks, the end result of this research may be that a feature request simply is not viable at the moment and would result in putting a stop to that work.
+
+Finally, spikes are usually **timeboxed**. However, given the open source/volunteer nature of our contributions, we do not enforce this for our contributors. When a timebox is set, this means that we are limiting how long we want someone to work on said spike. We do this to prevent contributors from falling into a rabbit hole they may never return from. Instead, we set a time limit to perform work on the spike and then have the assignee report back. If the tasks defined in the spike have not yet been completed, a decision is made on whether it makes sense to perform further work on the spike.
+
+#### When do I create a spike?
+
+A spike should be created when we do not have enough information to move forward with solving a problem. That simply means that, whenever we are dealing with unknowns or processes the project team has never encountered before, it may be useful for us to create a spike.
+
+In day-to-day work, this kind of situation may appear when new bug reports or feature requests come in that deal with problems or technologies that the project team is unfamiliar with. All issues that the project team has sufficient knowledge of should instead proceed as regular issues.
+
+#### When do I not create a spike?
+
+Below are some common scenarios where creating a spike is not appropriate:
+
+- Writing a technical specification for a feature we know how to implement
+- Design work that would go into drafting how an API is going to look and function
+- Any work that must be completed or is not optional
+
+## Working on Issues
+
+### How do I assign myself to an issue I am actively reviewing?
+
+If you do **not** have permissions, please indicate that you are working on an issue by leaving a comment. Someone who has permissions will assign you to the issue. If two weeks have passed without a pull request or an additional comment requesting information, you may be removed from the issue and the issue reassigned.
+
+If you are assigned to an issue but will not be able to continue work on it, please comment to indicate that you will no longer be working on it and press `unassign me` next to your username in the `Assignees` section of the issue page (top right).
+
+If you **do** have permissions, please assign yourself to the issue by pressing `assign myself` under the `Assignees` section of the issue page (top right).
=====================================
MANIFEST.in
=====================================
@@ -0,0 +1,4 @@
+include \
+ setup.h CHANGELOG.md CODE_OF_CONDUCT.md HOW_WE_USE_GITHUB.md LICENSE \
+ Makefile README.rst picosat.c picosat.h pycosat.c test_pycosat.py
+graft examples/
=====================================
RELEASE.md
=====================================
@@ -0,0 +1,406 @@
+<!-- These docs are updated and synced from https://github.com/conda/infra -->
+
+<!-- (TODO: the first three links here should be updated with the `repo.url` syntax once it works!) -->
+[epic template]: https://github.com/conda/conda/issues/new?assignees=&labels=epic&template=epic.yml
+[compare]: https://github.com/conda/infrastructure/compare
+[new release]: https://github.com/conda/infrastructure/releases/new
+<!-- links -->
+[infrastructure]: https://github.com/conda/infrastructure
+[rever docs]: https://regro.github.io/rever-docs
+[release docs]: https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes
+[merge conflicts]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/about-merge-conflicts
+[Anaconda Recipes]: https://github.com/AnacondaRecipes/conda-feedstock
+[conda-forge]: https://github.com/conda-forge/conda-feedstock
+
+# Release Process
+
+> **Note:**
+> Throughout this document are references to the version number as `YY.M.[$patch_number]`, this should be replaced with the correct version number. Do **not** prefix the version with a lowercase `v`.
+
+## 1. Open the release issue and cut a release branch. (do this ~1 week prior to release)
+
+> **Note:**
+> The new release branch should adhere to the naming convention of `YY.M.x` (make sure to put the `.x` at the end!). In the case of patch/hotfix releases, however, do NOT cut a new release branch; instead, use the previously-cut release branch with the appropriate `YY.M.x` version numbers.
+
+Use the issue template below to create the release issue. After creating the release issue, pin it for easy access.
+
+<details>
+<summary><code>GitHub Issue Template</code></summary>
+
+```markdown
+### Summary
+
+Placeholder for `{{ repo.name }} YY.M.x` release.
+
+| Pilot | <pilot> |
+|---|---|
+| Co-pilot | <copilot> |
+
+### Tasks
+
+[milestone]: {{ repo.url }}/milestone/<milestone>
+[process]: {{ repo.url }}/blob/main/RELEASE.md
+[releases]: {{ repo.url }}/releases
+[main]: https://github.com/AnacondaRecipes/{{ repo.name }}-feedstock
+[conda-forge]: https://github.com/conda-forge/{{ repo.name }}-feedstock
+[ReadTheDocs]: https://readthedocs.com/projects/continuumio-{{ repo.name }}/
+
+#### The week before release week
+
+- [ ] Create release branch (named `YY.M.x`)
+- [ ] Ensure release candidates are being successfully built (see `conda-canary/label/rc-{{ repo.name }}-YY.M.x`)
+- [ ] [Complete outstanding PRs][milestone]
+- [ ] Test release candidates
+ <!-- indicate here who has signed off on testing -->
+
+#### Release week
+
+- [ ] Create release PR (see [release process][process])
+- [ ] [Publish release][releases]
+- [ ] Activate the `YY.M.x` branch on [ReadTheDocs][ReadTheDocs]
+- [ ] Feedstocks
+ - [ ] Bump version & update dependencies/tests in [Anaconda, Inc.'s feedstock][main]
+ - [ ] Bump version & update dependencies/tests in [conda-forge feedstock][conda-forge]
+ <!-- link any other feedstock PRs here -->
+- [ ] Hand off to the Anaconda packaging team
+- [ ] Announce release
+ - Blog Post (optional)
+ - [ ] conda.org (link to pull request)
+ - Long form
+ - [ ] Create release [announcement draft](https://github.com/conda/communications)
+ - [ ] [Discourse](https://conda.discourse.group/)
+ - [ ] [Matrix (conda/conda)](https://matrix.to/#/#conda_conda:gitter.im) (this auto posts from Discourse)
+ - Summary
+ - [ ] [Twitter](https://twitter.com/condaproject)
+```
+</details>
+
+> **Note:**
+> The [epic template][epic template] is perfect for this; remember to remove the **`epic`** label.
+
+## 2. Alert various parties of the upcoming release. (do this ~1 week prior to release)
+
+Let various interested parties know about the upcoming release; at minimum, conda-forge maintainers should be informed. For major features, a blog post describing the new features should be prepared and posted once the release is completed (see the announcements section of the release issue).
+
+## 3. Ensure `rever.xsh` and `news/TEMPLATE` are up to date.
+
+These are synced from [`conda/infrastructure`][infrastructure].
+
+<details>
+<summary><h2>4. Run rever. (ideally done on the Monday of release week)</h2></summary>
+
+Currently, there are only 2 activities we use rever for, (1) aggregating the authors and (2) updating the changelog. Aggregating the authors can be an error-prone process and also suffers from builtin race conditions (_i.e._, to generate an updated `.authors.yml` we need an updated `.mailmap` but to have an updated `.mailmap` we need an updated `.authors.yml`). This is why the following steps are very heavy-handed (and potentially repetitive) in running rever commands, undoing commits, squashing/reordering commits, etc.
+
+1. Install [`rever`][rever docs] and activate the environment:
+
+ ```bash
+ $ conda create -n rever conda-forge::rever
+ $ conda activate rever
+ (rever) $
+ ```
+
+2. Clone and `cd` into the repository if you haven't done so already:
+
+ ```bash
+ (rever) $ git clone git at github.com:{{ repo.user }}/{{ repo.name }}.git
+ (rever) $ cd conda
+ ```
+
+2. Fetch the latest changes from the remote and checkout the release branch created a week ago:
+
+ ```bash
+ (rever) $ git fetch upstream
+ (rever) $ git checkout YY.M.x
+ ```
+
+2. Create a versioned branch, this is where rever will make its changes:
+
+ ```bash
+ (rever) $ git checkout -b changelog-YY.M.[$patch_number]
+ ```
+
+2. Run `rever --activities authors`:
+
+ > **Note:**
+ > Include `--force` when re-running any rever commands for the same `<VERSION>`, otherwise, rever will skip the activity and no changes will be made (i.e., rever remembers if an activity has been run for a given version).
+
+ ```bash
+ (rever) $ rever --activities authors --force <VERSION>
+ ```
+
+ - If rever finds that any of the authors are not correctly represented in `.authors.yml` it will produce an error. If the author that the error pertains to is:
+ - **a new contributor**: the snippet suggested by rever should be added to the `.authors.yml` file.
+ - **an existing contributor**, a result of using a new name/email combo: find the existing author in `.authors.yml` and add the new name/email combo to that author's `aliases` and `alterative_emails`.
+
+ - Once you have successfully run `rever --activities authors` with no errors, review the commit made by rever. This commit will contain updates to one or more of the author files (`.authors.yml`, `.mailmap`, and `AUTHORS.md`). Due to the race condition between `.authors.yml` and `.mailmap`, we want to extract changes made to any of the following keys in `.authors.yml` and commit them separately from the other changes in the rever commit:
+ - `name`
+ - `email`
+ - `github`
+ - `aliases`
+ - `alternate_emails`
+
+ Other keys (e.g., `num_commits` and `first_commit`) do not need to be included in this separate commit as they will be overwritten by rever.
+
+ - Here's a sample run where we undo the commit made by rever in order to commit the changes to `.authors.yml` separately:
+
+ ```bash
+ (rever) $ rever --activities authors --force YY.M.[$patch_number]
+
+ # changes were made to .authors.yml as per the prior bullet
+ (rever) $ git diff --name-only HEAD HEAD~1
+ .authors.yml
+ .mailmap
+ AUTHORS.md
+
+ # undo commit
+ (rever) $ git reset --soft HEAD~1
+
+ # undo changes made to everything except .authors.yml
+ (rever) $ git restore --staged --worktree .mailmap AUTHORS.md
+ ```
+
+ - Commit these changes to `.authors.yml`:
+
+ ```bash
+ (rever) $ git add .
+ (rever) $ git commit -m "Update .authors.yml"
+ ```
+
+ - Rerun `rever --activities authors` and finally check that your `.mailmap` is correct by running:
+
+ ```bash
+ git shortlog -se
+ ```
+
+ Compare this list with `AUTHORS.md`. If they have any discrepancies, additional modifications to `.authors.yml` is needed, so repeat the above steps as needed.
+
+ - Once you are pleased with how the author's file looks, we want to undo the rever commit and commit the `.mailmap` changes separately:
+
+ ```bash
+ # undo commit (but preserve changes)
+ (rever) $ git reset --soft HEAD~1
+
+ # undo changes made to everything except .mailmap
+ (rever) $ git restore --staged --worktree .authors.yml AUTHORS.md
+ ```
+
+ - Commit these changes to `.mailmap`:
+
+ ```bash
+ (rever) $ git add .
+ (rever) $ git commit -m "Update .mailmap"
+ ```
+
+ - Continue repeating the above processes until the `.authors.yml` and `.mailmap` are corrected to your liking. After completing this, you will have at most two commits on your release branch:
+
+ ```bash
+ (rever) $ git cherry -v main
+ + 86957814cf235879498ed7806029b8ff5f400034 Update .authors.yml
+ + 3ec7491f2f58494a62f1491987d66f499f8113ad Update .mailmap
+ ```
+
+
+4. Review news snippets (ensure they are all using the correct Markdown format, **not** reStructuredText) and add additional snippets for undocumented PRs/changes as necessary.
+
+ > **Note:**
+ > We've found it useful to name news snippets with the following format: `<PR #>-<DESCRIPTIVE SLUG>`.
+ >
+ > We've also found that we like to include the PR #s inline with the text itself, e.g.:
+ >
+ > ```markdown
+ > ## Enhancements
+ >
+ > * Add `win-arm64` as a known platform (subdir). (#11778)
+ > ```
+
+ - You can utilize [GitHub's compare view][compare] to review what changes are to be included in this release.
+
+ - Add a new news snippet for any PRs of importance that are missing.
+
+ - Commit these changes to news snippets:
+
+ ```bash
+ (rever) $ git add .
+ (rever) $ git commit -m "Update news"
+ ```
+
+ - After completing this, you will have at most three commits on your release branch:
+
+ ```bash
+ (rever) $ git cherry -v main
+ + 86957814cf235879498ed7806029b8ff5f400034 Update .authors.yml
+ + 3ec7491f2f58494a62f1491987d66f499f8113ad Update .mailmap
+ + 432a9e1b41a3dec8f95a7556632f9a93fdf029fd Update news
+ ```
+
+5. Run `rever --activities changelog`:
+
+ > **Note:**
+ > This has previously been a notoriously fickle step (likely due to incorrect regex patterns in the `rever.xsh` config file and missing `github` keys in `.authors.yml`) so beware of potential hiccups. If this fails, it's highly likely to be an innocent issue.
+
+ ```bash
+ (rever) $ rever --activities changelog --force <VERSION>
+ ```
+
+ - Any necessary modifications to `.authors.yml`, `.mailmap`, or the news snippets themselves should be amended to the previous commits.
+
+ - Once you have successfully run `rever --activities changelog` with no errors simply revert the last commit (see the next step for why):
+
+ ```bash
+ # undo commit (and discard changes)
+ (rever) $ git reset --hard HEAD~1
+ ```
+
+ - After completing this, you will have at most three commits on your release branch:
+
+ ```bash
+ (rever) $ git cherry -v main
+ + 86957814cf235879498ed7806029b8ff5f400034 Update .authors.yml
+ + 3ec7491f2f58494a62f1491987d66f499f8113ad Update .mailmap
+ + 432a9e1b41a3dec8f95a7556632f9a93fdf029fd Update news
+ ```
+
+6. Now that we have successfully run the activities separately, we wish to run both together. This will ensure that the contributor list, a side-effect of the authors activity, is included in the changelog activity.
+
+ ```bash
+ (rever) $ rever --force <VERSION>
+ ```
+
+ - After completing this, you will have at most five commits on your release branch:
+
+ ```bash
+ (rever) $ git cherry -v main
+ + 86957814cf235879498ed7806029b8ff5f400034 Update .authors.yml
+ + 3ec7491f2f58494a62f1491987d66f499f8113ad Update .mailmap
+ + 432a9e1b41a3dec8f95a7556632f9a93fdf029fd Update news
+ + a5c0db938893d2c12cab12a1f7eb3e646ed80373 Update authorship for YY.M.[$patch_number]
+ + 5e95169d0df4bcdc2da9a6ba4a2561d90e49f75d Update CHANGELOG for YY.M.[$patch_number]
+ ```
+
+7. Since rever does not include stats on first-time contributors, we will need to add this manually.
+
+ - Use [GitHub's auto-generated release notes][new release] to get a list of all new contributors (and their first PR) and manually merge this list with the contributor list in `CHANGELOG.md`. See [GitHub docs][release docs] for how to auto-generate the release notes.
+
+ - Commit these final changes:
+
+ ```bash
+ (rever) $ git add .
+ (rever) $ git commit -m "Add first-time contributions"
+ ```
+
+ - After completing this, you will have at most six commits on your release branch:
+
+ ```bash
+ (rever) $ git cherry -v main
+ + 86957814cf235879498ed7806029b8ff5f400034 Update .authors.yml
+ + 3ec7491f2f58494a62f1491987d66f499f8113ad Update .mailmap
+ + 432a9e1b41a3dec8f95a7556632f9a93fdf029fd Update news
+ + a5c0db938893d2c12cab12a1f7eb3e646ed80373 Update authorship for YY.M.[$patch_number]
+ + 5e95169d0df4bcdc2da9a6ba4a2561d90e49f75d Update CHANGELOG for YY.M.[$patch_number]
+ + 93fdf029fd4cf235872c12cab12a1f7e8f95a755 Add first-time contributions
+ ```
+
+8. Push this versioned branch.
+
+ ```bash
+ (rever) $ git push -u upstream changelog-YY.M.[$patch_number]
+ ```
+
+9. Open the Release PR targing the `YY.M.x` branch.
+
+ <details>
+ <summary>GitHub PR Template</summary>
+
+ ```markdown
+ ## Description
+
+ ✂️ snip snip ✂️ the making of a new release.
+
+ Xref #<RELEASE ISSUE>
+ ```
+
+ </details>
+
+10. Update release issue to include a link to the release PR.
+
+11. [Create][new release] the release and **SAVE AS A DRAFT** with the following values:
+
+ > **Note:**
+ > Only publish the release after the release PR is merged, until then always **save as draft**.
+
+ | Field | Value |
+ |---|---|
+ | Choose a tag | `YY.M.[$patch_number]` |
+ | Target | `YY.M.x` |
+ | Body | copy/paste blurb from `CHANGELOG.md` |
+
+</details>
+
+## 5. Wait for review and approval of release PR.
+
+## 6. Manually test canary build(s).
+
+### Canary Builds for Manual Testing
+
+Once the release PRs are filed, successful canary builds will be available on `https://anaconda.org/conda-canary/conda/files?channel=rc-{{ repo.name }}-YY.M.x` for manual testing.
+
+> **Note:**
+> You do not need to apply the `build::review` label for release PRs; every commit to the release branch builds and uploads canary builds to the respective `rc-` label.
+
+## 7. Merge release PR and publish release.
+
+To publish the release, go to the project's release page (e.g., https://github.com/conda/conda/releases) and add the release notes from `CHANGELOG.md` to the draft release you created earlier. Then publish the release.
+
+> **Note:**
+> Release notes can be drafted and saved ahead of time.
+
+## 8. Merge/cherry pick the release branch over to the `main` branch.
+
+<details>
+<summary>Internal process</summary>
+
+1. From the main "< > Code" page of the repository, select the drop down menu next to the `main` branch button and then select "View all branches" at the very bottom.
+
+2. Find the applicable `YY.M.x` branch and click the "New pull request" button.
+
+3. "Base" should point to `main` while "Compare" should point to `YY.M.x`.
+
+4. Ensure that all of the commits being pulled in look accurate, then select "Create pull request".
+
+> **Note:**
+> Make sure NOT to push the "Update Branch" button. If there are [merge conflicts][merge conflicts], create a temporary "connector branch" dedicated to fixing merge conflicts separately from the `YY.M.x` and `main` branches.
+
+5. Review and merge the pull request the same as any code change pull request.
+
+> **Note:**
+> The commits from the release branch need to be retained in order to be able to compare individual commits; in other words, a "merge commit" is required when merging the resulting pull request vs. a "squash merge". Protected branches will require permissions to be temporarily relaxed in order to enable this action.
+
+</details>
+
+## 9. Open PRs to bump [Anaconda Recipes][Anaconda Recipes] and [conda-forge][conda-forge] feedstocks to use `YY.M.[$patch_number]`.
+
+> **Note:**
+> Conda-forge's PRs will be auto-created via the `regro-cf-autotick-bot`. Follow the instructions below if any changes need to be made to the recipe that were not automatically added (these instructions are only necessary for anyone who is _not_ a conda-forge feedstock maintainer, since maintainers can push changes directly to the autotick branch):
+> - Create a new branch based off of autotick's branch (autotick's branches usually use the `regro-cf-autotick-bot:XX.YY.[$patch_number]_[short hash]` syntax)
+> - Add any changes via commits to that new branch
+> - Open a new PR and push it against the `main` branch
+>
+> Make sure to include a comment on the original `autotick-bot` PR that a new pull request has been created, in order to avoid duplicating work! `regro-cf-autotick-bot` will close the auto-created PR once the new PR is merged.
+>
+> For more information about this process, please read the ["Pushing to regro-cf-autotick-bot branch" section of the conda-forge documentation](https://conda-forge.org/docs/maintainer/updating_pkgs.html#pushing-to-regro-cf-autotick-bot-branch).
+
+
+## 10. Hand off to Anaconda's packaging team.
+
+<details>
+<summary>Internal process</summary>
+
+1. Open packaging request in #package_requests Slack channel, include links to the Release PR and feedstock PRs.
+
+2. Message packaging team/PM to let them know that a release has occurred and that you are the release manager.
+
+</details>
+
+## 11. Continue championing and shepherding.
+
+Remember to make all relevant announcements and continue to update the release issue with the latest details as tasks are completed.
=====================================
pycosat.c
=====================================
@@ -5,7 +5,7 @@
uses an MIT style license.
*/
#define PYCOSAT_URL "https://pypi.python.org/pypi/pycosat"
-#define PYCOSAT_VERSION "0.6.4"
+#define PYCOSAT_VERSION "0.6.6"
#include <Python.h>
@@ -70,14 +70,13 @@ static int blocksol(PicoSAT *picosat, signed char *mem)
{
int max_idx, i;
- max_idx = picosat_variables(picosat);
if (mem == NULL) {
- mem = PyMem_Malloc(max_idx + 1);
- if (mem == NULL) {
- PyErr_NoMemory();
- return -1;
- }
+ // caller must allocate picosat_variables(it->picosat) + 1 bytes
+ return -1;
}
+
+ max_idx = picosat_variables(picosat);
+
for (i = 1; i <= max_idx; i++)
mem[i] = (picosat_deref(picosat, i) > 0) ? 1 : -1;
@@ -272,7 +271,12 @@ static PyObject* itersolve(PyObject *self, PyObject *args, PyObject *kwds)
if (it->picosat == NULL)
return NULL;
- it->mem = NULL;
+ it->mem = PyMem_Calloc(picosat_variables(it->picosat) + 1, 1);
+ if (it->mem == NULL) {
+ PyErr_NoMemory();
+ return NULL;
+ }
+
PyObject_GC_Track(it);
return (PyObject *) it;
}
=====================================
rever.xsh
=====================================
@@ -0,0 +1,34 @@
+$ACTIVITIES = ["authors", "changelog"]
+
+# Basic settings
+$PROJECT = $GITHUB_REPO = $(basename $(git remote get-url origin)).split('.')[0].strip()
+$GITHUB_ORG = "conda"
+
+# Authors settings
+$AUTHORS_FILENAME = "AUTHORS.md"
+$AUTHORS_SORTBY = "alpha"
+
+# Changelog settings
+$CHANGELOG_FILENAME = "CHANGELOG.md"
+$CHANGELOG_PATTERN = r"\[//\]: # \(current developments\)"
+$CHANGELOG_HEADER = """[//]: # (current developments)
+
+## $VERSION ($RELEASE_DATE)
+
+"""
+$CHANGELOG_CATEGORIES = [
+ "Enhancements",
+ "Bug fixes",
+ "Deprecations",
+ "Docs",
+ "Other",
+]
+$CHANGELOG_CATEGORY_TITLE_FORMAT = "### {category}\n\n"
+$CHANGELOG_AUTHORS_TITLE = "Contributors"
+$CHANGELOG_AUTHORS_FORMAT = "* @{github}\n"
+
+try:
+ # allow repository to customize synchronized-from-infa rever config
+ from rever_overrides import *
+except ImportError:
+ pass
=====================================
setup.py
=====================================
@@ -5,48 +5,42 @@ from distutils.core import setup, Extension
# Read version from pycosat.c
pat = re.compile(r'#define\s+PYCOSAT_VERSION\s+"(\S+)"', re.M)
-data = open('pycosat.c').read()
+data = open("pycosat.c").read()
version = pat.search(data).group(1)
-ext_kwds = dict(
- name = "pycosat",
- sources = ["pycosat.c"],
- define_macros = []
-)
+ext_kwds = dict(name="pycosat", sources=["pycosat.c"], define_macros=[])
-if '--inplace' in sys.argv:
- ext_kwds['define_macros'].append(('DONT_INCLUDE_PICOSAT', 1))
- ext_kwds['library_dirs'] = ['.']
- ext_kwds['libraries'] = ['picosat']
+if "--inplace" in sys.argv:
+ ext_kwds["define_macros"].append(("DONT_INCLUDE_PICOSAT", 1))
+ ext_kwds["library_dirs"] = ["."]
+ ext_kwds["libraries"] = ["picosat"]
setup(
- name = "pycosat",
- version = version,
- author = "Ilan Schnell",
- author_email = "ilan at continuum.io",
- url = "https://github.com/ContinuumIO/pycosat",
- license = "MIT",
- classifiers = [
+ name="pycosat",
+ version=version,
+ author="Ilan Schnell",
+ author_email="ilan at continuum.io",
+ url="https://github.com/ContinuumIO/pycosat",
+ license="MIT",
+ classifiers=[
"Development Status :: 6 - Mature",
"Intended Audience :: Developers",
"Operating System :: OS Independent",
"Programming Language :: C",
"Programming Language :: Python :: 2",
- "Programming Language :: Python :: 2.5",
- "Programming Language :: Python :: 2.6",
"Programming Language :: Python :: 2.7",
"Programming Language :: Python :: 3",
- "Programming Language :: Python :: 3.2",
- "Programming Language :: Python :: 3.3",
- "Programming Language :: Python :: 3.4",
- "Programming Language :: Python :: 3.5",
- "Programming Language :: Python :: 3.6",
+ "Programming Language :: Python :: 3.7",
+ "Programming Language :: Python :: 3.8",
+ "Programming Language :: Python :: 3.9",
+ "Programming Language :: Python :: 3.10",
+ "Programming Language :: Python :: 3.11",
"Topic :: Utilities",
],
- ext_modules = [Extension(**ext_kwds)],
- py_modules = ['test_pycosat'],
- description = "bindings to picosat (a SAT solver)",
- long_description = open('README.rst').read(),
+ ext_modules=[Extension(**ext_kwds)],
+ py_modules=["test_pycosat"],
+ description="bindings to picosat (a SAT solver)",
+ long_description=open("README.rst").read(),
)
View it on GitLab: https://salsa.debian.org/med-team/python-pycosat/-/commit/48345dbdd267b7c4df2da9cb87ea193fbed1b308
--
View it on GitLab: https://salsa.debian.org/med-team/python-pycosat/-/commit/48345dbdd267b7c4df2da9cb87ea193fbed1b308
You're receiving this email because of your account on salsa.debian.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debian-med-commit/attachments/20231130/016770fc/attachment-0001.htm>
More information about the debian-med-commit
mailing list