accumulo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r965615 - in /websites/staging/accumulo/trunk/content: ./ verifying_releases.html
Date Wed, 16 Sep 2015 03:12:41 GMT
Author: buildbot
Date: Wed Sep 16 03:12:40 2015
New Revision: 965615

Staging update by buildbot for accumulo

    websites/staging/accumulo/trunk/content/   (props changed)

Propchange: websites/staging/accumulo/trunk/content/
--- cms:source-revision (original)
+++ cms:source-revision Wed Sep 16 03:12:40 2015
@@ -1 +1 @@

Modified: websites/staging/accumulo/trunk/content/verifying_releases.html
--- websites/staging/accumulo/trunk/content/verifying_releases.html (original)
+++ websites/staging/accumulo/trunk/content/verifying_releases.html Wed Sep 16 03:12:40 2015
@@ -34,7 +34,7 @@
   <script src="/js/dataTables.bootstrap.js"></script>
   <link href="/css/accumulo.css" rel="stylesheet" type="text/css">
   <link href="//" rel="stylesheet">
-  <title>Making a Release</title>
+  <title>Verifying a Release</title>
@@ -216,7 +216,7 @@ Latest 1.5 release: <strong>1.5.3</stron
   <div id="content">
-    <h1 class="title">Making a Release</h1>
+    <h1 class="title">Verifying a Release</h1>
     <style type="text/css">
 /* The following code is added by
@@ -229,111 +229,44 @@ Latest 1.5 release: <strong>1.5.3</stron
   visibility: hidden;
 h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover
> .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink
{ visibility: visible }</style>
-<p>This is a guide for the creation of a release of Apache Accumulo. </p>
-<h2 id="setup">Setup<a class="headerlink" href="#setup" title="Permanent link">&para;</a></h2>
-<p>There are number of things that are required before attempting to build a release.</p>
-<li>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 <code>default-cache-ttl 6000</code> 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 <a href="">ASF
release signing documentation</a>.</li>
-<li>Make sure the system you're using is able to create RPMs and DEBs.</li>
-<li>Ensure that you're using the correct major release of Java (check javadoc too).</li>
-<li>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).</li>
-<li>Update the CHANGES file so that it's in sync with Jira (manual process).</li>
-<li>Ensure that you have a texlive distribution installed so you are able to build
the documentation.</li>
-<li>Have a clean workspace before starting.</li>
-<p>Given all of this, it's recommended that you only attempt making a release from
a GNU/Linux machine.</p>
-<h2 id="create-the-candidate">Create the candidate<a class="headerlink" href="#create-the-candidate"
title="Permanent link">&para;</a></h2>
-<li><code>./assemble/ --create-release-candidate</code> to make
the release candidate</li>
-<li><code>git tag $version $version-rcN</code> to create an RC tag from
the actual tag</li>
-<li><code>git tag -d $version</code> make sure you don't accidentally push
a "release" tag</li>
-<li><code>git push origin $version-rcN</code> push the RC tag</li>
-<li><code>git checkout -b $version-rcN-branch</code> save off the branch
from the Maven release plugin</li>
-<li><em>If vote fails</em>, fix the original branch and start over.</li>
-<li><em>If vote passes</em>, <code>git merge $version-rcN-branch</code>
back into the original branch you released from.</li>
-<li><code>git tag -s $version-rcN $version</code> make a GPG-signed tag</li>
-<li><code>git push origin $version</code> push the signed tag.</li>
-<p><strong>Long-winded explanation</strong></p>
-<p>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.</p>
-<p>When invoking with the --create-release-candidate option, the majority
of the work will be performed
-by the maven-release-plugin, invoking <em>release:clean</em>, <em>release:prepare</em>,
and <em>release:perform</em>. 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 <em>not</em> 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.</p>
-<p>One unwanted side-effect of this approach is that after creating this branch, but
<em>before invoking release:perform</em>,
-you must edit the to add the <em>-rcN</em> 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 <em>mvn release:perform</em>,
-a staging repository will be made for you on the <a href="">ASF
Nexus server</a> which you can log into with your ASF 
-<p>After you log into Nexus, click on <em>Staging Repositories</em> in
the <em>Build Promotion</em> 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.</p>
-<h2 id="vote">Vote<a class="headerlink" href="#vote" title="Permanent link">&para;</a></h2>
-<p>At this point, you should have a closed repository that's ready to vote on. Send
a message to <a href="">the dev
-list</a> 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.</p>
-<p>If the vote passes, huzzah, you're almost done. All you need to do is to promote
that stage repository
-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.</p>
-<h2 id="copy-artifacts-to-distapacheorg">Copy artifacts to<a class="headerlink"
href="#copy-artifacts-to-distapacheorg" title="Permanent link">&para;</a></h2>
-<p>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
-<h2 id="update-projectsapacheorg">Update<a class="headerlink"
href="#update-projectsapacheorg" title="Permanent link">&para;</a></h2>
-<p>Fill out the <a href="">add
release</a> form to update the projects website.</p>
-<h2 id="update-the-website">Update the Website<a class="headerlink" href="#update-the-website"
title="Permanent link">&para;</a></h2>
-<p>After a successful vote, this website needs to be updated with the new artifacts.</p>
-<li>Copy Accumulo User Manual (HTML version exists in &gt;=1.7.0)</li>
-<li>Update downloads page</li>
-<li>Create release notes (ensure notes contain link to JIRA changes for that version)</li>
-<li>Remove previous bug-fix release (if applicable)</li>
-<li>Update examples README files</li>
-<h3 id="javadocs">Javadocs<a class="headerlink" href="#javadocs" title="Permanent
-<p>Javadocs are a little convoluted to update. First off, be sure that the javadocs
are <a href="">patched</a> <strong>before</strong>
-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 <a href="">extpaths</a>.
You can follow the steps below to update
-the javadocs.</p>
-<li>Build the javadocs <code>mvn clean compile javadoc:aggregate</code></li>
-<li>Run the vulnerability-check tool</li>
-<li>Checkout the <a href="">Accumulo
CMS repository</a></li>
-<li>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)</li>
-<li>Remove the appropriate entry from content/extpaths.txt (e.g. 1.6/apidocs for 1.6
-<li>Commit the changes</li>
-<li>Wait for the staging build to complete, and then publish the changes to the production
-<li>Remove the apidocs folder you created from the CMS repository (e.g. content/1.6/apidocs)</li>
-<li>Re-add the entry in extpaths.txt that you previously removed.</li>
-<li>Commit the changes</li>
-<li>Wait for the staging build to complete, and then publish the changes to the production
site again.</li>
-<li>Verify that javadocs have been updated on the production site</li>
-<h2 id="references">References<a class="headerlink" href="#references" title="Permanent
-<p>Some good references that explain a few things:</p>
-<li><a href="">Christopher
talks about making releases</a></li>
-<li><a href="">Publishing
Maven Artifacts</a></li>
-<li><a href="">Publishing Releases</a></li>
-<li><a href="">Accumulo Release
+<p>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.</p>
+<p>The information here is meant to be an application of Foundation policy. When in
doubt or conflict, any Foundation-level
+trumps anything written here.</p>
+<p>Verification of a release candidate can be broken down into three categories.</p>
+<h2 id="accumulo-correctness">Accumulo Correctness<a class="headerlink" href="#accumulo-correctness"
title="Permanent link">&para;</a></h2>
+<p>Testing a distributed database is, arguably, the easiest of these requirements.</p>
+<p>Accumulo contains unit and integration tests which can be automatically run via
Maven. These tests can be invoked
+by issues the following commands:</p>
+<div class="codehilite"><pre>$ <span class="n">mvn</span> <span
+<p>Additionally, Accumulo contains multiple distributed tests, most notably the RandomWalk
and ContinuousIngest tests.
+Information on these tests can be found in their respective directories, <code>test/system/randomwalk</code>
+ <code>test/system/continuous</code>, 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.</p>
+<h2 id="foundation-level-requirements">Foundation Level Requirements<a class="headerlink"
href="#foundation-level-requirements" title="Permanent link">&para;</a></h2>
+<p>The ASF requires that all artifacts in a release are cryptographically signed and
distributed with hashes.</p>
+<p>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. <code>sha1sum</code>, <code>md5sum</code>).</p>
+<p>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.</p>
+<p>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.</p>
+<h2 id="apache-software-license-application">Apache Software License Application<a
class="headerlink" href="#apache-software-license-application" title="Permanent link">&para;</a></h2>
+<p>Application of the Apache Software License v2 consists of the following steps on
each artifact in a release.</p>
+<h3 id="license-file">LICENSE file<a class="headerlink" href="#license-file" title="Permanent
+<p>The LICENSE file should be present at the top-level of an artifact. This file should
be explicitly named <code>LICENSE</code>,
+however <code>LICENSE.txt</code> 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 <em>contained
in the given
+artifact</em> 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.</p>
   <div id="footer">
@@ -357,7 +290,7 @@ the javadocs.</p>
 <script type="text/javascript">

View raw message