update pre-release docs

docs/development/release_management.rst

@@ -14,14 +14,34 @@ Pre-Release
 1. Open a **Release SecureDrop 1.x.y** issue to track release-related activity.
    Keep this issue updated as you proceed through the release process for
    transparency.
-#. Check if there is a new stable release of Tor that can be QAed and released
-   as part of the SecureDrop release. If so, file an issue.
-#. Check if a release candidate for the Tails release is prepared. If so, request
+
+#. Check if there is a new stable release of Tor that can be QAed and released as part of the 
+   SecureDrop release. You can find stable releases by checking the `Tor blog 
+   <https://blog.torproject.org/category/tags/stable-release>`_. If we can upgrade, file an issue
+   and upgrade Tor following these steps:
+
+      a. Bump the version in `fetch-tor-packages
+         <https://github.com/freedomofpress/securedrop/blob/develop/molecule/fetch-tor-packages/
+         playbook.yml>`_ and open a PR.
+
+      b. Run ``make fetch-tor-packages`` to download the new debs (this will use Secure apt under 
+         the hood to verify the Release file and package), copy the downloaded packages into the 
+         ``securedrop-dev-packages-lfs`` repo, and open a PR so that a reviewer can verify that
+         the checksums match the checksums of the packages hosted on the `Tor apt 
+         repo <https://deb.torproject.org/torproject.org/pool/main/>`_. Once the PR is merged, the 
+         packages will be resigned with our own Release key, replacing Tor's, and hosted on 
+         ``apt-test.freedom.press``. 
+
+#. Check if a new release or release candidate for Tails has been added to the `Tails apt repo 
+   <https://deb.tails.boum.org/dists/>`_. If so, request
    people participating in QA to use the latest release candidate.
-#. Ensure that a pre-release announcement is prepared and shared with the community
-   for feedback. Once the announcement is ready, coordinate with other team members to
-   send them to current administrators, post on the SecureDrop blog, and tweet
-   out a link.
+
+#. Work with the Communications Manager assigned for the release to prepare a pre-release 
+   announcement that will be shared on the support.freedom.press support portal, securedrop.org 
+   website, and Twitter. Wait until the day of the release before including an announcmement for a 
+   SecureDrop security update. For a point release, you may be able to skip the pre-release 
+   announcement depending on how small the point release is.
+
 #. For a regular release for version 1.x.0, branch off ``develop``::
 
      git checkout develop
@@ -188,26 +208,10 @@ Release Process
 #. Ask Infrastructure to perform the DNS cutover to switch
    ``apt-qa.freedom.press`` to ``apt.freedom.press``. Once complete,
    the release is live.
-#. Make sure that the default branch of documentation is being built
-   off the tip of the release branch. Building from the branch instead
-   of a given tag enables us to more easily add documentation changes
-   after release. You should:
-
-   a. Log into readthedocs.
-   #. Navigate to **Projects** → **securedrop** → **Versions** →
-      **Inactive Versions** → **release/branch** → **Edit**.
-   #. Mark the branch as Active by checking the box and save your
-      changes. This will kick off a new docs build.
-   #. Once the documentation has built, it will appear in the version
-      selector at the bottom of the column of the.
-   #. Now set this new release as default by navigating to **Admin** →
-      **Advanced Settings** → **Global Settings** → **Default
-      Version**.
-   #. Select ``release/branch`` from the dropdown menu and save the
-      changes.
-   #. Verify that docs.securedrop.org redirects users to the
-      documentation built from the release branch.
-
+#. Issue a PR to merge the release branch changes into ``master``. Once the PR is
+   merged, verify that the `public documentation <https://docs.securedrop.org/>`_
+   refers to the new release version. If not, log in to ReadTheDocs and start a
+   build of the ``master`` version.
 #. Create a `release
    <https://github.com/freedomofpress/securedrop/releases>`_ on GitHub
    with a brief summary of the changes in this release.
@@ -222,10 +226,24 @@ Release Process
 Post-Release
 ------------
 
-After the release, carefully monitor the FPF support portal (or ask those that have access to
-monitor) and SecureDrop community support forum for any issues that users are
-having.
-
-Finally, in a PR back to develop, cherry-pick the release commits (thus ensuring a consistent
-changelog in the future) and bump the version numbers
-in preparation for the next release (this is required for the upgrade testing scenario).
+Now it's time to backport the changelog from the release branch into the ``develop`` branch and bump
+the SecureDrop version so that it's ready for the next round of QA testing.
+
+We backport the changelog by cherry-picking any commits that modified ``changelog.md`` during the
+release. You can look at the file history by checking out the release branch and running: 
+``git log --pretty=oneline changelog.md``. The output will contain the commit hashes associated with 
+the release. Create a new branch based on ``develop`` and cherry-pick these commits using the
+``-x`` flag.
+
+Now you're ready to bump the SecureDrop version on your new branch. There are a bunch of version
+files that'll need to be updated in order to set up the upgrade test for the next release. We do
+this by running the version-updater script and specifying the new version number, which will be the
+next minor version with ``~rc1`` appended. For example, if the release is 1.3.0, then you'll run: 
+``securedrop/bin/dev-shell ../update_version.sh 1.4.0~rc1``  (``dev-shell`` is a script that starts
+a container so that we can ensure ``dch`` is installed). Accept all the default changes from the
+``update_version.sh`` script. You'll only need to add your commit message. Once you're done, sign
+your commit and make a PR to merge these changes into ``develop``.
+
+The only thing left to do is to monitor the `FPF support portal <https://support.freedom.press>`_
+and the `SecureDrop community support forum <https://forum.securedrop.org/c/support>`_ for any new
+user issues related to the release. 

securedrop/models.py

@@ -665,6 +665,7 @@ def login(cls, username, password, token):
         # type: (str, str, str) -> Journalist
         try:
             user = Journalist.query.filter_by(username=username).one()
+            return user
         except NoResultFound:
             raise InvalidUsernameException(
                 "invalid username '{}'".format(username))