Merge pull request #249 from ngoldbaum/docs-fixes

Update release instructions

docs/wiki/dev-guides/Local-Development-Setup.md

@@ -6,7 +6,6 @@
   - [Create your fork](#create-your-fork)
   - [Configure remotes](#configure-remotes)
   - [Authenticating with GitHub](#authenticating-with-github)
-  - [Configure commit signing](#configure-commit-signing)
 - [Guidelines](#guidelines)
 
 ## Step 1: Build CSP from Source
@@ -31,19 +30,7 @@ already set that way and click "Create fork".
 ### Configure remotes
 
 Next, you should set some names for the `git` remotes corresponding to
-main Point72 repository and your fork. If you started with a clone of
-the main `Point72` repository, you could do something like:
-
-```bash
-cd csp
-git remote rename origin upstream
-
-# for SSH authentication
-git remote add origin [email protected]:<username>/csp.git
-
-# for HTTP authentication
-git remote add origin https://github.com/<username>/csp.git
-```
+main Point72 repository and your fork. See the [GitHub Docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-repository-for-a-fork) for more information.
 
 ### Authenticating with GitHub
 
@@ -59,25 +46,6 @@ or adding a [personal access
 token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens)
 to avoid the need to type in your password every time you push to your fork.
 
-### Configure commit signing
-
-Additionally, you will need to configure your local `git` setup and
-GitHub account to use [commit
-signing](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification). All
-commits to the `csp` repository must be signed to increase the
-difficulty of a supply-chain attack against the CSP codebase. The
-easiest way to do this is to [configure `git` to sign commits with your
-SSH
-key](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#ssh-commit-signature-verification). You
-can also use a [GPG
-key](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#gpg-commit-signature-verification)
-to sign commits.
-
-In either case, you must also add your public key to your github account
-as a signing key. Note that if you have already added an SSH key as an
-authentication key, you will need to add it again [as a signing
-key](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account).
-
 ## Guidelines
 
 After developing a change locally, ensure that both [lints](Build-CSP-from-Source#lint-and-autoformat) and [tests](Build-CSP-from-Source#testing) pass. Commits should be squashed into logical units, and all commits must be signed (e.g. with the `-s` git flag). CSP requires [Developer Certificate of Origin](https://en.wikipedia.org/wiki/Developer_Certificate_of_Origin) for all contributions.

docs/wiki/dev-guides/Release-Process.md

@@ -10,6 +10,7 @@
     - [Download release artifacts from github actions](#download-release-artifacts-from-github-actions)
     - [Optionally upload to testpypi to test "pip install"](#optionally-upload-to-testpypi-to-test-pip-install)
     - [Upload to pypi](#upload-to-pypi)
+  - [Releasing to conda-forge](#releasing-to-conda-forge)
 - [Dealing with release mistakes](#dealing-with-release-mistakes)
 
 ## Doing a "normal" release
@@ -74,12 +75,10 @@ Follow these steps when it's time to tag a new release. Before doing
 this, you will need to ensure `bump2version` is installed into your
 development environment.
 
-> \[!NOTE\]
-> The following steps assume you have a personal fork of csp.
-> If you are working from the main `Point72/csp` repo, use `origin`
-> instead of `upstream` in the git commands. Specifically,
-> `git pull origin main --tags` in the step 1,
-> and `git push origin main --follow-tags` in step 7.
+> The following steps assume you are pushing to the main `Point72/csp`
+> repo. If you are working from a personal fork, use the corresponding
+> remote (e.g. `upstream`) instead of `origin` in all git commands.
+> Ensure tags are still pushed to `Point72/csp` directly.
 
 1. Ensure your local clone of `csp` is synced up with GitHub, including
    any tags that have been pushed since you last synced:
@@ -99,16 +98,17 @@ development environment.
    git checkout -b release/v0.x.x
    ```
 
-   For example, for a bugfix release, `bump2version` will automatically
-   update the codebase to use the next bugfix version number if you do:
+   You can update the version number in the codebase using `bump2version`. For a
+   bugfix release, you would do:
 
    ```bash
    make patch
    ```
 
    Similarly, `make minor` and `make major` will update the version
    numbers for minor and major releases, respectively. Double-check
-   that the version numbers have been updated correctly with `git  diff`, and then `git commit -s` the change.
+   that the version numbers have been updated correctly with
+   `git diff`, and then `git commit -s` the change.
 
 1. Push your branch to GitHub, and trigger a "full" test run on the branch.
 
@@ -118,7 +118,8 @@ development environment.
    button is selected, and click the green "Run workflow" button to
    launch the test run.
 
-1. Propose a pull request from the branch containing the version number updated. Add a link to the successful full test run for reviewers.
+1. Propose a pull request from the branch containing the version number updated.
+   Add a link to the successful full test run for reviewers.
 
 1. Review and merge the pull request. Make sure you delete the branch
    afterwards.
@@ -132,10 +133,10 @@ development environment.
    git tag v0.2.0
    ```
 
-1. Push the tag to GitHub
+1. Push the tag to GitHub using the tag name created in the previous step.
 
    ```bash
-   git push upstream main --follow-tags
+   git push origin tag v0.2.0
    ```
 
    You will need access in the repository settings to be able to push
@@ -249,6 +250,17 @@ View at:
 https://pypi.org/project/csp/<version number>/
 ```
 
+### Releasing to conda-forge
+
+The `conda-forge` release process is largely automated. Maintainers who
+are listed under the `extra.recipe-maintainers` field in the `csp`
+recipe hosted in [the conda-forge feedstock
+repository](https://github.com/conda-forge/csp-feedstock/blob/main/recipe/meta.yaml)
+should be automatically subscribed to notifications for the
+repository. The [conda-forge maintainer documentation](https://conda-forge.org/docs/maintainer/updating_pkgs/)
+has the relevant guidelines and procedures, and should be read thoroughly before
+making any changes.
+
 ## Dealing with release mistakes
 
 Sometimes releases go wrong. Here is what to do when that happens. This