adoroszlai commented on code in PR #67:
URL: https://github.com/apache/ozone-site/pull/67#discussion_r1473154590


##########
docs/08-developer-guide/04-project/02-release-guide.md:
##########
@@ -6,15 +6,22 @@ sidebar_label: Release Manager Guide
 
 This document describes the process to release Apache Ozone. The process is 
not yet scripted, and the documentation is **a work in progress**.
 
-## Pre-Requisite
+## Pre-Requisites
 
-The release manager should have a GPG key set up to sign the artifacts. For 
help creating your key refer to the [ASF new committer 
guide](https://www.apache.org/dev/new-committers-guide.html#set-up-security-and-pgp-keys).
+### Install Required Packages
 
-## Publish Your GPG Key
+In addition to the usual development tools required to work on Ozone, the 
following packages are required during the release process:
+  - [Subversion](https://subversion.apache.org/) to publish release artifacts 
and GPG keys.
+  - [GnuPG](https://www.gnupg.org/) to manage your GPG keys.
+  - [protolock](https://github.com/nilslice/protolock) to manage protocol 
buffer compatibility.
 
-The release manager's GPG key is supposed to be published together with the 
release. Please append it to the end of the [KEYS 
file](https://dist.apache.org/repos/dist/release/ozone/KEYS) if it is not 
already present by using SVN.
+### Publish Your GPG Key
 
-```bash title="Publish key (committer)"
+Create a GPG key to sign the artifacts if you do not already have one. For 
help creating your key refer to the [ASF new committer 
guide](https://www.apache.org/dev/new-committers-guide.html#set-up-security-and-pgp-keys).
 The release manager's GPG key is supposed to be published together with the 
release. Please use Subversion to append it to the end of the [KEYS 
file](https://dist.apache.org/repos/dist/release/ozone/KEYS) if it is not 
already present.

Review Comment:
   ```suggestion
   Create a GPG key to sign the artifacts if you do not already have one. For 
help creating your key refer to the [ASF new committer 
guide](https://www.apache.org/dev/new-committers-guide.html#set-up-security-and-pgp-keys).
 The release manager's GPG key is supposed to be published together with the 
release. Please append it to the end of the [KEYS 
file](https://dist.apache.org/repos/dist/release/ozone/KEYS) stored in 
Subversion, if it is not already present.
   ```



##########
docs/08-developer-guide/04-project/02-release-guide.md:
##########
@@ -179,39 +193,39 @@ for i in $(ls -1 *.tar.gz); do gpg --print-mds "$i" > 
"$i.mds"; done
 
 Now each .tar.gz file should have an associated .mds file, .asc file, and 
.sha512 file
 
-### Check the artifacts
+### Check the Artifacts
 
 Before uploading the artifacts, run some basic tests on them, similar to what 
other devs will run before voting in favor of the release.
 
- 1. Extract the contents of the source tarball and build it with an empty 
maven cache by renaming your `~/.m2` directory before doing the build.
- 2. Check the size of the output binary tarball for significant size increase 
from the last release.
-    * A significant increase in size could indicate a dependency issue that 
needs to be fixed.
-    * The Apache svn repo has a size limit for release artifacts. If uploading 
svn fails because the tarball is too big, we need to contact INFRA to increase 
our repo size. [See here for 
details.](https://issues.apache.org/jira/browse/INFRA-23892)
- 3. Verify signatures
-    * Download the KEYS file from 
[https://dist.apache.org/repos/dist/release/ozone/KEYS](https://dist.apache.org/repos/dist/release/ozone/KEYS)
-    * Import its contents (which should include your public gpg key): `gpg 
--import KEYS`
-    * Verify each .tar.gz artifact: `gpg --verify <artifact>.tar.gz.asc 
<artifact>.tar.gz`
- 4. Verify checksums
-    * Run `shasum -a 512 *.tar.gz`
-    * Verify that the output checksums for each artifact match the contents of 
its .sha512 file and the SHA512 line in its .mds file.
- 5. Make sure docs are present in the release tarball
-    * There should be a directory called docs in the top level. If there is 
not, then `hugo` was not installed during the build and it must be re-done.
-    * Extract the release and open docs/index.html in your web browser, and 
check that the documentation website looks ok.
- 6. Check the output of running `bin/ozone version` from the extracted release 
tarball
-    * After extracting the release, the output of this command should contain:
-      * The correct release
-      * The correct national park tag
-      * A non-snapshot version of Ratis.
-      * A link to the apache/ozone GitHub repository (not your fork).
-      * The git hash of the last commit the release was built on.
- 7. Run the Ozone upgrade acceptance tests by running `test.sh` from the 
compose/upgrade directory in the extracted release tarball.
-    * This check is also run by the GitHub actions CI for each commit, so it 
should pass with no surprises.
-
-### Upload the artifacts dev staging area
-
- * Upload everything from the `$RELEASE_DIR` to the dev staging area.
-
-```bash title="Upload artifacts to staging"
+1. Extract the contents of the source tarball and build it with an empty maven 
cache by renaming your `~/.m2` directory before doing the build.
+2. Check the size of the output binary tarball for significant size increase 
from the last release.
+  - A significant increase in size could indicate a dependency issue that 
needs to be fixed.
+  - The Apache svn repo has a size limit for release artifacts. If uploading 
svn fails because the tarball is too big, we need to contact INFRA to increase 
our repo size. [See here for 
details.](https://issues.apache.org/jira/browse/INFRA-23892)
+3. Verify signatures
+  - Download the KEYS file from 
[https://dist.apache.org/repos/dist/release/ozone/KEYS](https://dist.apache.org/repos/dist/release/ozone/KEYS)
+  - Import its contents (which should include your public gpg key): `gpg 
--import KEYS`
+  - Verify each .tar.gz artifact: `gpg --verify <artifact>.tar.gz.asc 
<artifact>.tar.gz`
+4. Verify checksums
+  - Run `shasum -a 512 *.tar.gz`
+  - Verify that the output checksums for each artifact match the contents of 
its .sha512 file and the SHA512 line in its .mds file.
+5. Make sure docs are present in the release tarball
+  - There should be a directory called docs in the top level. If there is not, 
then `hugo` was not installed during the build and it must be re-done.
+  - Extract the release and open docs/index.html in your web browser, and 
check that the documentation website looks ok.
+6. Check the output of running `bin/ozone version` from the extracted release 
tarball
+  - After extracting the release, the output of this command should contain:
+    - The correct release
+    - The correct national park tag
+    - A non-snapshot version of Ratis.
+    - A link to the apache/ozone GitHub repository (not your fork).
+    - The git hash of the last commit the release was built on.
+7. Run the Ozone upgrade acceptance tests by running `test.sh` from the 
compose/upgrade directory in the extracted release tarball.
+  - This check is also run by the GitHub actions CI for each commit, so it 
should pass with no surprises.
+
+### Upload the Artifacts Dev Staging Area

Review Comment:
   ```suggestion
   ### Upload the Artifacts to Dev Staging
   ```



##########
docs/08-developer-guide/04-project/02-release-guide.md:
##########
@@ -23,28 +30,32 @@ gpg --armor --export $CODESIGNINGKEY >> KEYS
 svn commit -m "ozone: adding key of <your_name> to the KEYS"
 ```
 
-In case you are only a committer and not a PMC member, you can add your key to 
the dev KEYS file and a PMC can move it to the final destination
+- If you are a committer and not a PMC member, you can add your key to the dev 
KEYS file and a PMC member can move it to the final destination:
 
-```bash title="Move key (PMC)"
-#use latest KEYS as the base
+```bash title="Publish Key (Committer)"
+# Use the latest KEYS as the base
 svn rm https://dist.apache.org/repos/dist/dev/ozone/KEYS
-svn cp https://dist.apache.org/repos/dist/release/ozone/KEYS  
https://dist.apache.org/repos/dist/dev/ozone/KEYS
+svn cp https://dist.apache.org/repos/dist/release/ozone/KEYS 
https://dist.apache.org/repos/dist/dev/ozone/KEYS
 
 svn co https://dist.apache.org/repos/dist/dev/ozone
 cd ozone
 export CODESIGNINGKEY=your_gpg_key_id
 gpg --list-sigs $CODESIGNINGKEY >> KEYS
 gpg --armor --export $CODESIGNINGKEY >> KEYS
-svn commit -m "ozone: adding key of XXXX to the KEYS"
+svn commit -m "ozone: adding key of <your_name> to the KEYS"
+```
+
+```bash title="Move Key (PMC)"
+svn cp -m "ozone: adding key of <name> to the KEYS" 
https://dist.apache.org/repos/dist/dev/ozone/KEYS 
https://dist.apache.org/repos/dist/release/ozone/KEYS
 ```
 
 ## Pre-Vote
 
-### Create a parent Jira for the release
+### Create a Parent Jira for the Release
 
 This provides visibility into the progress of the release for the community. 
Tasks mentioned in this guide like cherry-picking fixes on to the release 
branch, updating the ozone website, publishing the docker image, etc can be 
added as subtasks.
 
-### Bulk comment on Jiras targeting this release
+### Bulk Comment on Jiras Targeting This Release
 
 Issue a Jira query like 
[this](https://issues.apache.org/jira/browse/HDDS-4183?jql=project%20%3D%20HDDS%20AND%20resolution%20%3D%20Unresolved%20AND%20(cf%5B12310320%5D%20%3D%201.3.0%20OR%20fixVersion%20%3D%201.3.0)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC),
 modified for the release number you are working with, to find all unresolved 
Jiras that have the target version field set to this release. Note that some 
people incorrectly use Fix Version as the Target Version, so Fix Version is 
included in this search. Use the following steps to issue a bulk update to 
these Jiras:

Review Comment:
   ```suggestion
   Issue a Jira query like 
[this](https://issues.apache.org/jira/issues/?jql=project%20%3D%20HDDS%20AND%20resolution%20%3D%20Unresolved%20AND%20(cf%5B12310320%5D%20%3D%201.3.0%20OR%20fixVersion%20%3D%201.3.0)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC),
 modified for the release number you are working with, to find all unresolved 
Jiras that have the target version field set to this release. Note that some 
people incorrectly use Fix Version as the Target Version, so Fix Version is 
included in this search. Use the following steps to issue a bulk update to 
these Jiras:
   ```



##########
docs/08-developer-guide/04-project/02-release-guide.md:
##########
@@ -220,14 +234,13 @@ svn add *
 svn commit -m "Ozone $VERSION RC$RC"
 ```
 
- * Check the results using your browser by connecting to 
[https://dist.apache.org/repos/dist/dev/ozone/](https://dist.apache.org/repos/dist/dev/ozone/)
-
+- Check the results using your browser by connecting to 
[https://dist.apache.org/repos/dist/dev/ozone/](https://dist.apache.org/repos/dist/dev/ozone/)

Review Comment:
   ```suggestion
   - Check the results by opening the [dev 
directory](https://dist.apache.org/repos/dist/dev/ozone/) in your browser.
   ```



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to