Author: buildbot
Date: Wed Sep 16 03:12:40 2015
New Revision: 965615
Log:
Staging update by buildbot for accumulo
Modified:
websites/staging/accumulo/trunk/content/ (props changed)
websites/staging/accumulo/trunk/content/verifying_releases.html
Propchange: websites/staging/accumulo/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Wed Sep 16 03:12:40 2015
@@ -1 +1 @@
-1703318
+1703321
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="//netdna.bootstrapcdn.com/font-awesome/4.0.3/css/font-awesome.css"
rel="stylesheet">
- <title>Making a Release</title>
+ <title>Verifying a Release</title>
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
@@ -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 mdx_elementid.py
@@ -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">¶</a></h2>
-<p>There are number of things that are required before attempting to build a
release.</p>
-<ol>
-<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="https://www.apache.org/dev/release-signing";>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>
-</ol>
-<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">¶</a></h2>
-<p><strong>TL;DR</strong></p>
-<ul>
-<li><code>./assemble/build.sh --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><strong>VOTE</strong></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>
-</ul>
-<p><strong>Long-winded explanation</strong></p>
-<p>You should use the provided script assemble/build.sh to create the release
candidate. This script is
-desirable as it activates all necessary maven profiles in addition to
verifying that certain preconditions
-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 build.sh 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
build.sh 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 release.properties 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="https://repository.apache.org/index.html";>ASF Nexus server</a> which you
can log into with your ASF
-credentials.</p>
-<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">¶</a></h2>
-<p>At this point, you should have a closed repository that's ready to vote on.
Send a message to <a href="mailto:d...@accumulo.apache.org";>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 dist.apache.org<a
class="headerlink" href="#copy-artifacts-to-distapacheorg" title="Permanent
link">¶</a></h2>
-<p>An SVN server is running at
https://dist.apache.org/repos/dist/release/accumulo. 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 dist.apache.org will still
be preserved in archive.apache.org
-automatically.</p>
-<h2 id="update-projectsapacheorg">Update projects.apache.org<a
class="headerlink" href="#update-projectsapacheorg" title="Permanent
link">¶</a></h2>
-<p>Fill out the <a
href="https://reporter.apache.org/addrelease.html?accumulo";>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">¶</a></h2>
-<p>After a successful vote, this website needs to be updated with the new
artifacts.</p>
-<ul>
-<li>Copy Accumulo User Manual (HTML version exists in >=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>
-</ul>
-<h3 id="javadocs">Javadocs<a class="headerlink" href="#javadocs"
title="Permanent link">¶</a></h3>
-<p>Javadocs are a little convoluted to update. First off, be sure that the
javadocs are <a href="http://www.kb.cert.org/vuls/id/225657";>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="http://www.apache.org/dev/cmsref#extpaths";>extpaths</a>. You can follow
the steps below to update
-the javadocs.</p>
-<ol>
-<li>Build the javadocs <code>mvn clean compile javadoc:aggregate</code></li>
-<li>Run the vulnerability-check tool</li>
-<li>Checkout the <a
href="https://svn.apache.org/repos/asf/accumulo/site/trunk";>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 release)</li>
-<li>Commit the changes</li>
-<li>Wait for the staging build to complete, and then publish the changes to
the production site.</li>
-<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>
-</ol>
-<h2 id="references">References<a class="headerlink" href="#references"
title="Permanent link">¶</a></h2>
-<p>Some good references that explain a few things:</p>
-<ul>
-<li><a
href="http://mail-archives.apache.org/mod_mbox/accumulo-dev/201305.mbox/raw/%3CCAL5zq9bH8y0FyjXmmfXhWPj8axosn9dZ7%2Bu-R1DK4Y-WM1YoWg%40mail.gmail.com%3E/";>Christopher
talks about making releases</a></li>
-<li><a
href="https://www.apache.org/dev/publishing-maven-artifacts.html";>Publishing
Maven Artifacts</a></li>
-<li><a href="http://www.apache.org/dev/release-publishing.html";>Publishing
Releases</a></li>
-<li><a href="http://accumulo.apache.org/governance/releasing.html";>Accumulo
Release Guide</a></li>
-</ul>
+<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">¶</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
class="n">verify</span>
+</pre></div>
+
+
+<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> and
+ <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">¶</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">¶</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 link">¶</a></h3>
+<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>
<div id="footer">
@@ -357,7 +290,7 @@ the javadocs.</p>
<script type="text/javascript">
-$("#nav_releasing").addClass("active");
+$("#nav_verify_release").addClass("active");
</script>
</body>
