opendev/gerrit
Code Issues Proposed changes

Merge branch 'stable-3.1' into stable-3.2

Browse Source 
* 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
This commit is contained in:
Marco Miller
2020-09-30 12:23:13 -04:00
parent 657407d463 e8b183b43e
commit 6a0c27b687
3 changed files with 59 additions and 41 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
Documentation/dev-e2e-tests.txt
View File

@@ -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.
1. 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.
1. This is due to the sbt-eclipse plugin not properly linking the Gerrit Gatling e2e tests with
2. Run `sbt eclipse` from the `e2e-tests` root directory.
3. Import the resulting `e2e-tests` eclipse file inside the Gerrit project, in Eclipse.
4. You should see errors in Eclipse telling you there are missing packages.
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.
1. Then you have to browse to `.sbt/1.0/staging`, find the folder where gatling-git is contained,
6. You then have to right-click on the root directory and choose the build path->link source option.
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

2
Documentation/dev-processes.txt
View File

@@ -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

82
Documentation/dev-release.txt
View File

@@ -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 versions:
* Verify the plugin 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
click on `Release`.
link:https://oss.sonatype.org/[Sonatype Nexus Server,role=external,window=_blank],
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:
* 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.
Submit that previously uploaded change on the homepage project.
[[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