Merge branch 'stable-3.1' into stable-3.2

* stable-3.1:
  Documentation: Fix #steering-committee link in dev-processes
  Documentation: Make some dev-release notes steps happen sooner
  Documentation: Remove extra blank lines in dev-release
  Documentation: Fix the asciidoctor warnings in dev-e2e-tests
  Documentation: Add dev-release clarification on signing tags
  Documentation: Remove redundant Verify line in dev-release

Add the few missing linkattrs in the hereby merged dev-release page.

Change-Id: I4f1b42fd06dec83de71eca4554269aa59b55032c

Documentation/dev-e2e-tests.txt

@@ -42,17 +42,17 @@ So, Eclipse can also be used alongside as a development IDE; this is described b
 === Eclipse
 
 1. Install the link:http://scala-ide.org/docs/user/gettingstarted.html[Scala plugin for Eclipse,role=external,window=_blank].
-1. Run `sbt eclipse` from the `e2e-tests` root directory.
+2. Run `sbt eclipse` from the `e2e-tests` root directory.
-1. Import the resulting `e2e-tests` eclipse file inside the Gerrit project, in Eclipse.
+3. Import the resulting `e2e-tests` eclipse file inside the Gerrit project, in Eclipse.
-1. You should see errors in Eclipse telling you there are missing packages.
+4. You should see errors in Eclipse telling you there are missing packages.
-1. This is due to the sbt-eclipse plugin not properly linking the Gerrit Gatling e2e tests with
+5. This is due to the sbt-eclipse plugin not properly linking the Gerrit Gatling e2e tests with
    Gatling Git plugin.
-1. You then have to right-click on the root directory and choose the build path->link source option.
+6. You then have to right-click on the root directory and choose the build path->link source option.
-1. Then you have to browse to `.sbt/1.0/staging`, find the folder where gatling-git is contained,
+7. Then you have to browse to `.sbt/1.0/staging`, find the folder where gatling-git is contained,
    and choose that.
-1. That last step should link the gatling-git plugin to the project; e2e tests should not show
+8. That last step should link the gatling-git plugin to the project; e2e tests should not show
    errors anymore.
-1. You may get errors in the gatling-git directory; these should not affect Gerrit Gatling
+9. You may get errors in the gatling-git directory; these should not affect Gerrit Gatling
    development and can be ignored.
 
 == How to build the tests

Documentation/dev-processes.txt

@@ -87,7 +87,7 @@ voting (for 2020 the voting period ends on Mon 18th May EOD).
 
 Google maintainers do not take part in this vote, because Google
 already has dedicated seats in the steering committee (see section
-link:steering-committee[steering committee]).
+link:#steering-committee[steering committee]).
 
 [[contribution-process]]
 == Contribution Process

Documentation/dev-release.txt

@@ -13,7 +13,6 @@ hopefully serve as both a how to for those new to the process
 and as a checklist for those already familiar with these
 tasks.
 
-
 == Gerrit Release Type
 
 Here are some guidelines on release approaches depending on the
@@ -42,7 +41,6 @@ There should be no new features in this release, only bug fixes
 
 * Finally create the `stable` release (no `rc`)
 
-
 === Stable-Fix
 
 `stable-fix` releases should likely only contain bug fixes and doc
@@ -53,7 +51,6 @@ updates.
 * This type of release does not need any RCs, release when the
 objectives are met
 
-
 [[security]]
 === Security-Fix
 
@@ -71,6 +68,40 @@ a `security-fix` release has been published will the commits/tags made in
 the `gerrit-security-fixes` project be taken over into the public
 `gerrit` project.
 
+[[upload-final-release-notes]]
+== Upload the final Release Notes change
+
+Upload a change on the homepage project to:
+
+* Remove 'In Development' caveat from the relevant section.
+
+* Add links to the released documentation and the .war file, and make the
+latest version bold.
+
+The uploaded change is not to be approved yet, but rather act as the
+release content review thread until it can be finalized.
+
+[[update-links]]
+=== Update homepage links
+
+Upload a change on the link:https://gerrit-review.googlesource.com/admin/repos/homepage[
+homepage project,role=external,window=_blank] to change the version numbers
+to the new version.
+
+[[update-issues]]
+=== Update the Issues
+
+Update the issues by hand. There is no script for this.
+
+Our current process is an issue should be updated to say `Status =
+Submitted, FixedIn-$version` once the change is submitted, but before the
+release.
+
+The updated issues are the ones listed in commit messages since the
+previous version tag. Mention each updated issue in the uploaded change,
+following the examples from the previous version notes. Add updated issue
+owners as reviewers of the uploaded change. More reviewers can be added
+or cc'ed, to further coordinate the final release contents.
 
 == Create the Actual Release
 
@@ -96,6 +127,16 @@ Commit the changes and create a signed release tag on the new commit:
   git tag -s -m "v$version" "v$version"
 ----
 
+If unable to tag, make sure that git is locally
+link:https://medium.com/@rwbutler/signing-commits-using-gpg-on-macos-7210362d15[
+configured with your user's key,role=external,window=_blank]. These are the
+macOS instructions but such commands should be portable enough. Setting
+`GPG_TTY` this way or similar might also be necessary:
+
+----
+  export GPG_TTY=$(tty)
+----
+
 Tag the plugins:
 
 ----
@@ -105,7 +146,7 @@ Tag the plugins:
 [[build-gerrit]]
 === Build Gerrit
 
-* Build the Gerrit WAR, API JARs and documentation
+* Build the Gerrit WAR, API JARs and documentation:
 +
 ----
   bazel build release Documentation:searchfree
@@ -120,9 +161,7 @@ Tag the plugins:
 ----
 * Try upgrading a test site and launching the daemon
 
-* Verify plugin versions
+* Verify the plugin versions:
-+
-Verify the versions:
 +
 ----
   java -jar bazel-bin/release.war init --list-plugins
@@ -163,7 +202,7 @@ repository and no further action is needed:
 https://oss.sonatype.org/content/repositories/snapshots/com/google/gerrit/[role=external,window=_blank]
 
 ** Release versions are uploaded into a staging repository in the
-link:https://oss.sonatype.org/[Sonatype Nexus Server].
+link:https://oss.sonatype.org/[Sonatype Nexus Server,role=external,window=_blank].
 
 * Verify the staging repository
 
@@ -215,8 +254,8 @@ Sonatype OSS Maven Repository Usage Guide,role=external,window=_blank].
 Releasing artifacts to Maven Central cannot be undone!
 
 ** Find the closed staging repository in the
-link:https://oss.sonatype.org/[Sonatype Nexus Server], select it and
+link:https://oss.sonatype.org/[Sonatype Nexus Server,role=external,window=_blank],
-click on `Release`.
+select it and click on `Release`.
 
 ** The released artifacts are available in
 https://oss.sonatype.org/content/repositories/releases/com/google/gerrit/[role=external,window=_blank]
@@ -236,7 +275,6 @@ link:https://oss.sonatype.org/[Sonatype Nexus Server,role=external,window=_blank
 
 ** Select `com.google.gerrit` as `Project`.
 
-
 [[publish-to-google-storage]]
 ==== Publish the Gerrit WAR to the Google Cloud Storage
 
@@ -258,7 +296,6 @@ get them merged.
 * Create a change updating the `defaultbranch` field in the `.gitreview`
 to match the branch name created.
 
-
 [[push-tag]]
 ==== Push the Release Tag
 
@@ -274,7 +311,6 @@ Push the new Release Tag on the plugins:
   git submodule foreach git push gerrit-review tag v$version
 ----
 
-
 [[upload-documentation]]
 ==== Upload the Documentation
 
@@ -289,34 +325,16 @@ gerrit-documentation,role=external,window=_blank] storage bucket.
 [[finalize-release-notes]]
 === Finalize the Release Notes
 
-Upload a change on the homepage project to:
+Submit that previously uploaded change on the homepage project.
-
-* Remove 'In Development' caveat from the relevant section.
-
-* Add links to the released documentation and the .war file, and make the
-latest version bold.
-
-[[update-links]]
-==== Update homepage links
-
-Upload a change on the link:https://gerrit-review.googlesource.com/admin/repos/homepage[
-homepage project,role=external,window=_blank] to change the version numbers to the new version.
 
 [[update-issues]]
 ==== Update the Issues
 
-Update the issues by hand. There is no script for this.
-
-Our current process is an issue should be updated to say `Status =
-Submitted, FixedIn-$version` once the change is submitted, but before the
-release.
-
 After the release is actually made, you can search in Google Code for
 `Status=Submitted FixedIn=$version` and then batch update these changes
 to say `Status=Released`. Make sure the pulldown says `All Issues`
 because `Status=Submitted` is considered a closed issue.
 
-
 [[announce]]
 ==== Announce on Mailing List