Author: jcvanderwal
Date: Fri Dec 21 16:11:01 2012
New Revision: 1424993
URL: http://svn.apache.org/viewvc?rev=1424993&view=rev
Log:
Added title to verify releases scripted paged
Modified:
isis/site/trunk/content/contributors/verifying-releases.md
Modified: isis/site/trunk/content/contributors/verifying-releases.md
URL:
http://svn.apache.org/viewvc/isis/site/trunk/content/contributors/verifying-releases.md?rev=1424993&r1=1424992&r2=1424993&view=diff
==============================================================================
--- isis/site/trunk/content/contributors/verifying-releases.md (original)
+++ isis/site/trunk/content/contributors/verifying-releases.md Fri Dec 21
16:11:01 2012
@@ -1,63 +1,62 @@
-Title: Verifying Releases
-
-Whenever a committer announces a vote on a release on the [dev mailing
list](../support.html), it is the responsibility of the project's PMC to cast
their vote on the release. Any other ASF member may also vote.
-
-This page provides some guidance on what a voter is expected to verify before
casting their vote.
-
-Per this [ASF documentation](http://www.apache.org/dev/release.html), the
legal requirements for an ASF release are:
-
-* a source zip file + corresponding signature (signed by me, which is in the
ASF web of trust and in our KEYS file)
-* all source files have the Apache license (this is ensured by the running of
the rat plugin prior to release; you could run it on the unzipped source)
-* all dependencies are appropriately licensed; see the `DEPENDENCIES` file
which is automatically generated from the POMs plus the supplemental-models.xml
file
-
-Note that the binaries are *not* an ASF release, they merely exist on the
Maven central repo as a convenience.
-
-
-## Verifying the source release artifacts
-
-Download both the ZIP and .ASC files from the location specified in the voting
email. To verify that the signature is correct, use:
-
-<pre>
-gpg --verify isis-x.y.z.zip.asc isis-x.y.z.zip
-</pre>
-
-### Building the source release artifacts
-
-Assuming the ZIP file verifies, it should be unpacked, and then the artifact
built from source.
-
-First, delete all Isis artifacts from your local Maven repo:
-
-<pre>
-rm -rf ~/.m2/repository/org/apache/isis
-</pre>
-
-The build process depends on whether the artifact is of Isis core or of one of
its components:
-
-* For Isis core, build using the `-o` offline flag:
-
- `mvn clean install -o`
-
- Confirm that the versions of the Isis artifacts now cached in your local
repository are correct.
-
-* For an Isis component, build without the offline flag; Maven should pull
down the component's dependencies from the Maven central repo:
-
- `mvn clean install`
-
- Confirm that the versions of the Isis artifacts now cached in your local
repository are correct (both those pulled down from Maven central repo, as well
as those of the component built locally).
-
-The above steps are the bare minimum you should perform before casting a vote.
Ideally, you should also run an Isis application (eg one of the examples)
against the new code (either against a new version of core, or configured to
use the new version of the component).
-
-## Verifying the binary release artifacts
-
-Optionally, you can verify the binary releases (in the Maven staging
repository). For this it is necessary to download each artifact from Nexus and
its corresponding .ASC file. Since there are many such artifacts, just verify
one or two at random.
-
-## Using the Creadur Tools
-
-The [Apache Creadur](http://creadur.apache.org) project exists to provide a
set of tools to ensure compliance with Apache's licensing standards. The main
release auditing tool, [Apache RAT](http://creadur.apache.org/rat), is used in
the preparation of the release (as documented [here](release-process.html)).
Creadur's remaining tools are to support the verification process.
-
-At the time of writing, these additional tools are quite young and haven't
been formally released; so to use them will take a little bit of work. See
[here](verifying-releases-using-creadur-tools.html) for more details.
-
-
-## Casting a Vote
-
-When you have made the above checks (and any other checks you think may be
relevant), cast your vote by replying to the email thread on the mailing list.
If you are casting `-1`, please provide details of the problem(s) you have
found.
+Title: Verifying releases using a script
+Whenever a committer announces a vote on a release on the [dev mailing
list](../support.html), it is the responsibility of the project's PMC to cast
their vote on the release. Any other ASF member may also vote.
+
+This page provides some guidance on what a voter is expected to verify before
casting their vote.
+
+Per this [ASF documentation](http://www.apache.org/dev/release.html), the
legal requirements for an ASF release are:
+
+* a source zip file + corresponding signature (signed by me, which is in the
ASF web of trust and in our KEYS file)
+* all source files have the Apache license (this is ensured by the running of
the rat plugin prior to release; you could run it on the unzipped source)
+* all dependencies are appropriately licensed; see the `DEPENDENCIES` file
which is automatically generated from the POMs plus the supplemental-models.xml
file
+
+Note that the binaries are *not* an ASF release, they merely exist on the
Maven central repo as a convenience.
+
+
+## Verifying the source release artifacts
+
+Download both the ZIP and .ASC files from the location specified in the voting
email. To verify that the signature is correct, use:
+
+<pre>
+gpg --verify isis-x.y.z.zip.asc isis-x.y.z.zip
+</pre>
+
+### Building the source release artifacts
+
+Assuming the ZIP file verifies, it should be unpacked, and then the artifact
built from source.
+
+First, delete all Isis artifacts from your local Maven repo:
+
+<pre>
+rm -rf ~/.m2/repository/org/apache/isis
+</pre>
+
+The build process depends on whether the artifact is of Isis core or of one of
its components:
+
+* For Isis core, build using the `-o` offline flag:
+
+ `mvn clean install -o`
+
+ Confirm that the versions of the Isis artifacts now cached in your local
repository are correct.
+
+* For an Isis component, build without the offline flag; Maven should pull
down the component's dependencies from the Maven central repo:
+
+ `mvn clean install`
+
+ Confirm that the versions of the Isis artifacts now cached in your local
repository are correct (both those pulled down from Maven central repo, as well
as those of the component built locally).
+
+The above steps are the bare minimum you should perform before casting a vote.
Ideally, you should also run an Isis application (eg one of the examples)
against the new code (either against a new version of core, or configured to
use the new version of the component).
+
+## Verifying the binary release artifacts
+
+Optionally, you can verify the binary releases (in the Maven staging
repository). For this it is necessary to download each artifact from Nexus and
its corresponding .ASC file. Since there are many such artifacts, just verify
one or two at random.
+
+## Using the Creadur Tools
+
+The [Apache Creadur](http://creadur.apache.org) project exists to provide a
set of tools to ensure compliance with Apache's licensing standards. The main
release auditing tool, [Apache RAT](http://creadur.apache.org/rat), is used in
the preparation of the release (as documented [here](release-process.html)).
Creadur's remaining tools are to support the verification process.
+
+At the time of writing, these additional tools are quite young and haven't
been formally released; so to use them will take a little bit of work. See
[here](verifying-releases-using-creadur-tools.html) for more details.
+
+
+## Casting a Vote
+
+When you have made the above checks (and any other checks you think may be
relevant), cast your vote by replying to the email thread on the mailing list.
If you are casting `-1`, please provide details of the problem(s) you have
found.
