doc: many process fixes / reorders

* Separate process into stages; stage 1 is preparation, stage 2 is
  staging, stage 3 is publishing
* Reorder some steps
* Remove some steps
* Elaborate on some steps
* Add some steps

Signed-off-by: Quentin Young <qlyoung@nvidia.com>

1 files changed, 61 insertions, 33 deletions

diff --git a/doc/developer/frr-release-procedure.rst b/doc/developer/frr-release-procedure.rst
index b4dd4d7de..11caedf1f 100644
--- a/doc/developer/frr-release-procedure.rst
+++ b/doc/developer/frr-release-procedure.rst
@@ -6,6 +6,9 @@ FRR Release Procedure
 ``<version>`` - version to be released, e.g. 7.3
 ``origin`` - FRR upstream repository
 
+Stage 1 - Preparation
+---------------------
+
 #. Checkout the existing ``dev/<version>`` branch.
 
    .. code-block:: console
@@ -18,7 +21,6 @@ FRR Release Procedure
    .. code-block:: console
 
       git checkout -b stable/<version>
-      git push origin stable/<version>:refs/heads/stable/<version>
 
 #. Remove the development branch called ``dev/<version>``
 
@@ -85,10 +87,6 @@ FRR Release Procedure
 
       debian, redhat: updating changelog for new release
 
-#. Create a new branch based on ``master``, cherry-pick the commit made in step
-   6, and use it to create a PR against ``master``. This way ``master`` has the
-   latest changelog for the next cycle.
-
 #. Change main version number:
 
    - Edit :file:`configure.ac` and change version in the ``AC_INIT`` command
@@ -102,13 +100,29 @@ FRR Release Procedure
    The version field should be complete; i.e. for ``8.0.0``, the version should
    be ``8.0.0`` and not ``8.0`` or ``8``.
 
+
+Stage 2 - Staging
+-----------------
+
 #. Push the stable branch to a new remote branch prefixed with ``rc``::
 
       git push origin stable/<version>:rc/version
 
    This will trigger the NetDEF CI, which serve as a sanity check on the
    release branch. Verify that all tests pass and that all package builds are
-   successful.
+   successful. To do this, go to the NetDEF CI located here:
+
+   https://ci1.netdef.org/browse/FRR-FRR
+
+   In the top left, look for ``rc-<version>`` in the "Plan branch" dropdown.
+   Select this version. Note that it may take a few minutes for the CI to kick
+   in on this new branch and appear in the list.
+
+#. Push the stable branch:
+
+   .. code-block:: console
+
+      git push origin stable/<version>:refs/heads/stable/<version>
 
 #. Create and push a git tag for the version:
 
@@ -117,34 +131,35 @@ FRR Release Procedure
       git tag -a frr-<version> -m "FRRouting Release <version>"
       git push origin frr-<version>
 
-#. Kick off the Release build plan on the CI system for the correct release.
+#. Create a new branch based on ``master``, cherry-pick the commit made earlier
+   that added the changelogs, and use it to create a PR against ``master``.
+   This way ``master`` has the latest changelog for the next cycle.
+
+#. Kick off the "Release" build plan on the CI system for the correct release.
    Contact Martin Winter for this step. Ensure all release packages build
    successfully.
 
 #. Kick off the Snapcraft build plan for the release.
 
-#. Acquire the release RPM binary packages from Martin Winter.
 
-#. On GitHub, go to the <https://github.com/FRRouting/frr/releases>_ and click
-   "Draft a new release". Write a release announcement. The release
-   announcement should follow the template in
-   ``release-announcement-template.md``, located next to this document. Check
-   for spelling errors, and optionally (but preferably) have other maintainers
-   proofread the announcement text.
+Stage 3 - Publish
+-----------------
+
+#. Upload both the Debian and RPM packages to their respective repositories.
+
+#. Coordinate with the maintainer of FRR's RPM repository to publish the RPM
+   packages on that repository. Update the repository webpage. Verify that the
+   instructions on the webpage work and that FRR is installable from the
+   repository on a Red Hat system.
 
-   Attach **only** the binary RPM packages to the GitHub release using
-   GitHub's attachment functionality. Do not attach Debian packages. Do not
-   attach source tarballs - these will be generated and attached by GitHub
-   automatically. Do not publish the release yet.
+   Current maintainer: *Martin Winter*
 
-#. Contact the current Debian maintainer for FRR to get new Debian packages
-   built and published on our APT repository at https://deb.frrouting.net/.
-   Ensure the webpage text is updated. Verify that new packages install
-   successfully on a vanilla Debian installation using the instructions on the
-   webpage.
+#. Coordinate with the maintainer of FRR Debian package to publish the Debian
+   packages on that repository. Update the repository webpage. Verify that the
+   instructions on the webpage work and that FRR is installable from the
+   repository on a Debian system.
 
-#. Deploy Snapcraft release (after CI system finishes the tests for snapcraft
-   testplan).
+   Current maintainer: *Jafar Al-Gharaibeh*
 
 #. Log in to the Read The Docs instance. in the "FRRouting" project, navigate
    to the "Overview" tab. Ensure there is a ``stable-<version>`` version listed
@@ -155,7 +170,25 @@ FRR Release Procedure
    This step must be performed by someone with administrative access to the
    Read the Docs instance.
 
-#. Publish the GitHub release.
+#. On GitHub, go to the <https://github.com/FRRouting/frr/releases>_ and click
+   "Draft a new release". Write a release announcement. The release
+   announcement should follow the template in
+   ``release-announcement-template.md``, located next to this document. Check
+   for spelling errors, and optionally (but preferably) have other maintainers
+   proofread the announcement text.
+
+   Do not attach any packages or source tarballs to the GitHub release.
+
+   Publish the release once it is reviewed.
+
+#. Deploy Snapcraft release. Remember that this will automatically upgrade Snap
+   users.
+
+   Current maintainer: *Martin Winter*
+
+#. Build and publish the Docker containers.
+
+   Current maintainer: *Quentin Young*
 
 #. Clone the ``frr-www`` repository:
 
@@ -192,10 +225,5 @@ FRR Release Procedure
    that the announcement text is visible.
 
 #. Send an email to ``announce@lists.frrouting.org``. The text of this email
-   should include the text from the GitHub release.
-
-#. Update masters version of the changelog-auto.in
-
-   Take the change data and cut-n-paste the changes into the master version
-   below the @VERSION@-0 lines.  So we have the history of the previous
-   release.
+   should include text as appropriate from the GitHub release and a link to the
+   GitHub release, Debian repository, and RPM repository.