accumulo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r1703321 - /accumulo/site/trunk/content/verifying_releases.mdtext
Date Wed, 16 Sep 2015 03:12:14 GMT
Author: elserj
Date: Wed Sep 16 03:12:13 2015
New Revision: 1703321

Start staging verification steps.


Modified: accumulo/site/trunk/content/verifying_releases.mdtext
--- accumulo/site/trunk/content/verifying_releases.mdtext (original)
+++ accumulo/site/trunk/content/verifying_releases.mdtext Wed Sep 16 03:12:13 2015
@@ -1,5 +1,5 @@
-Title: Making a Release
-Nav: nav_releasing
+Title: Verifying a Release
+Nav: nav_verify_release
 Notice:    Licensed to the Apache Software Foundation (ASF) under one
            or more contributor license agreements.  See the NOTICE file
            distributed with this work for additional information
@@ -17,138 +17,57 @@ Notice:    Licensed to the Apache Softwa
            specific language governing permissions and limitations
            under the License.
-This is a guide for the creation of a release of Apache Accumulo. 
+This is a guide for the verification of a release candidate of Apache Accumulo. These steps
are meant to encapsulate
+the requirements of the PMC set forth by the Foundation itself.
+The information here is meant to be an application of Foundation policy. When in doubt or
conflict, any Foundation-level
+trumps anything written here.
+Verification of a release candidate can be broken down into three categories.
+## Accumulo Correctness ##
+Testing a distributed database is, arguably, the easiest of these requirements.
+Accumulo contains unit and integration tests which can be automatically run via Maven. These
tests can be invoked
+by issues the following commands:
+    $ mvn verify
+Additionally, Accumulo contains multiple distributed tests, most notably the RandomWalk and
ContinuousIngest tests.
+Information on these tests can be found in their respective directories, `test/system/randomwalk`
+ `test/system/continuous`, which include instructions on how to run the tests. These tests
are intended to be run
+for days on end while injecting faults into the system. These are the tests that truly verify
the correctness of
+Accumulo on real systems.
+## Foundation Level Requirements ##
+The ASF requires that all artifacts in a release are cryptographically signed and distributed
with hashes.
+OpenPGP is an asymmetric encryption scheme which lends itself well to the globally distributed
nature of Apache.
+Verification of a release artifact can be done using the signature and the release-maker's
public key. Hashes
+can be verified using the appropriate command (e.g. `sha1sum`, `md5sum`).
+An Apache release must contain a source-only artifact. This is the official release artifact.
While a release of
+and Apache project can contain other artifacts that do contain binary files. These non-source
artifacts are for
+user convenience only, but still must adhere to the same licensing rules.
+PMC members should take steps to verify that the source-only artifact does not contain any
binary files. There is
+some leeway in this rule. For example, test-only binary artifacts (such as test files or
jars) are acceptable as long
+as they are only used for testing the software and not running it.
+## Apache Software License Application ##
+Application of the Apache Software License v2 consists of the following steps on each artifact
in a release.
+### LICENSE file ###
+The LICENSE file should be present at the top-level of an artifact. This file should be explicitly
named `LICENSE`,
+however `LICENSE.txt` is acceptable but not preferred. This file contains the text of the
Apache Software License 
+at the top of the file. At the bottom of the file, all other open source licenses _contained
in the given
+artifact_ must be listed at the bottom of the LICENSE file. Contained components that are
licensed with the ASL themselves
+do not need to be included in this file. It is common to see inclusions in file such as the
MIT License of 3-clause
+BSD License.
-## Setup
-There are number of things that are required before attempting to build a release.
-1. Use gpg-agent, and be sure to increase the gpg-agent cache timeout (via .gnupg/gpg-agent.conf)
to ensure that the agent doesn't require re-authentication mid-build, as it will cause things
to fail. For example, you can add `default-cache-ttl 6000` to increase the timeout from the
default of 10 minutes to over an hour. If you do not have a GPG key, reference the very thorough
[ASF release signing documentation][1].
-2. Make sure the system you're using is able to create RPMs and DEBs.
-3. Ensure that you're using the correct major release of Java (check javadoc too).
-4. Ensure that you're building Apache Accumulo with a username that has the same name as
your Apache ID (this is due to
-   the maven-release-plugin and staging the release candidate).
-5. Update the CHANGES file so that it's in sync with Jira (manual process).
-6. Ensure that you have a texlive distribution installed so you are able to build the documentation.
-7. Have a clean workspace before starting.
-Given all of this, it's recommended that you only attempt making a release from a GNU/Linux
-## Create the candidate
-* `./assemble/ --create-release-candidate` to make the release candidate
-* `git tag $version $version-rcN` to create an RC tag from the actual tag
-* `git tag -d $version` make sure you don't accidentally push a "release" tag
-* `git push origin $version-rcN` push the RC tag
-* `git checkout -b $version-rcN-branch` save off the branch from the Maven release plugin
-* **VOTE**
-* *If vote fails*, fix the original branch and start over.
-* *If vote passes*, `git merge $version-rcN-branch` back into the original branch you released
-* `git tag -s $version-rcN $version` make a GPG-signed tag
-* `git push origin $version` push the signed tag.
-**Long-winded explanation**
-You should use the provided script assemble/ to create the release candidate. This
script is
-desirable as it activates all necessary maven profiles in addition to verifying that certain
-are met, like RPM signing availablilty and the ability to sign files using GPG. The --test
option can 
-be used as a dry run for creating a release candidate. The --create-release-candidate option
should be 
-used to create the actual release candidate.
-When invoking with the --create-release-candidate option, the majority of the work
will be performed
-by the maven-release-plugin, invoking *release:clean*, *release:prepare*, and *release:perform*.
These will
-guide you through choosing the correct versions. The default options provided should be what
you choose.
-It is highly recommended that an 'RC' suffix is *not* appended to the release version the
plugin prompts
-you for, as that will result in that version string being placed into the poms, which then
would require 
-voting to occur on artifacts that cannot be directly promoted. After the script
finishes (this will 
-likely take at least 15 minutes, even on recent hardware), your current branch will be on
the "next" version 
-that you provided to the release plugin.
-One unwanted side-effect of this approach is that after creating this branch, but *before
invoking release:perform*,
-you must edit the to add the _-rcN_ suffix to the value of scm.tag. Otherwise,
the release
-plugin will complain that it cannot find the branch for the release. With a successful invocation
of *mvn release:perform*,
-a staging repository will be made for you on the [ASF Nexus server][2] which you can log
into with your ASF 
-After you log into Nexus, click on _Staging Repositories_ in the _Build Promotion_ toolbar
on the left side of
-the screen. Assuming your build went according to plan, you should have a new staging repository
made for
-you. At this point, you should inspect the artifacts that were staged to ensure that they
are as you expect
-them to be. When you're ready to present those artifacts for voting, you need to close that
repository which
-will make it publicly available for other members to inspect.
-## Vote
-At this point, you should have a closed repository that's ready to vote on. Send a message
to [the dev
-list]( and get the ball rolling. If the vote ultimately fails,
you delete
-the staged repository, clean up the branch you created (or wait until the release ultimately
passes if you
-choose), and fix what needs fixing.
-If the vote passes, huzzah, you're almost done. All you need to do is to promote that stage
-using Nexus which you can do with the click of a button. This will trigger a process to get
the release
-out to all of the mirrors.
-## Copy artifacts to
-An SVN server is running at You need
to upload the release
-tarballs, the GPG signatures and checksum files to the correct directory (based on the release
number). If you
-are releasing a bug-fix release, be sure to delete the previous release in the same line
(e.g. if you release
-1.6.2, remove 1.6.1). The old tarballs removed from will still be preserved
-## Update
-Fill out the [add release][addrelease] form to update the projects website.
-## Update the Website
-After a successful vote, this website needs to be updated with the new artifacts.
-  * Copy Accumulo User Manual (HTML version exists in >=1.7.0)
-  * Update downloads page
-  * Create release notes (ensure notes contain link to JIRA changes for that version)
-  * Remove previous bug-fix release (if applicable)
-  * Update examples README files
-### Javadocs
-Javadocs are a little convoluted to update. First off, be sure that the javadocs are [patched][7]
-uploading as long as Java 6 is the version targeted by Accumulo (with greater than Java 7u21
being used once we
-switch to Java 7). Despite the javadocs not appearing in the CMS SVN repository, this is
-where they need to be committed using [extpaths][8]. You can follow the steps below to update
-the javadocs.
-1. Build the javadocs `mvn clean compile javadoc:aggregate`
-2. Run the vulnerability-check tool
-3. Checkout the [Accumulo CMS repository][9]
-4. Copy the entire apidocs folder in the appropriate version folder in the CMS repository
(e.g. content/1.6/apidocs for a 1.6 release)
-5. Remove the appropriate entry from content/extpaths.txt (e.g. 1.6/apidocs for 1.6 release)
-6. Commit the changes
-7. Wait for the staging build to complete, and then publish the changes to the production
-8. Remove the apidocs folder you created from the CMS repository (e.g. content/1.6/apidocs)
-9. Re-add the entry in extpaths.txt that you previously removed.
-10. Commit the changes
-11. Wait for the staging build to complete, and then publish the changes to the production
site again.
-12. Verify that javadocs have been updated on the production site
-## References
-Some good references that explain a few things:
-- [Christopher talks about making releases][3]
-- [Publishing Maven Artifacts][4]
-- [Publishing Releases][5]
-- [Accumulo Release Guide][6]

View raw message