This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/accumulo-website.git
The following commit(s) were added to refs/heads/asf-staging by this push:
new 05e7cbec Automatic Site Publish by Buildbot
05e7cbec is described below
commit 05e7cbecf06ee653db0982a540590a89e78fa236
Author: buildbot <us...@infra.apache.org>
AuthorDate: Tue Oct 25 16:20:53 2022 +0000
Automatic Site Publish by Buildbot
---
output/contributor/verifying-release.html | 195 ++++++++++++++++--------------
output/feed.xml | 4 +-
2 files changed, 104 insertions(+), 95 deletions(-)
diff --git a/output/contributor/verifying-release.html
b/output/contributor/verifying-release.html
index 40ad14d5..c0973432 100644
--- a/output/contributor/verifying-release.html
+++ b/output/contributor/verifying-release.html
@@ -142,11 +142,9 @@
<h1 class="title">Verifying a Release</h1>
- <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>This is a guide to help verify the quality of a release or
release candidate. The testing described
+here is not a requirement of the Foundation, but may be useful to help PMC
members decide how they
+wish to vote for a release candidate.</p>
<h2 id="versioning">Versioning</h2>
@@ -159,93 +157,101 @@ trumps anything written here.</p>
<p>Below are some suggested tests that can be run (feel free to run your own
custom tests too):</p>
<ul>
- <li>
- <p>Run Accumulo’s unit and integration tests using the following
command:</p>
-
- <div class="language-plaintext highlighter-rouge"><div
class="highlight"><pre class="highlight"><code> $ mvn verify
-</code></pre></div> </div>
- </li>
- <li>
- <p>Build the <a
href="https://github.com/apache/accumulo-examples";>Accumulo Examples</a> repo
using the release candidate by updating the <code class="language-plaintext
highlighter-rouge">accumulo.version</code>
-property in the <code class="language-plaintext
highlighter-rouge">pom.xml</code> and using the staging repo. Also, run the
unit/integration tests using <code class="language-plaintext
highlighter-rouge">mvn verify</code>.</p>
- </li>
- <li>
- <p>Run Accumulo’s distributed tests (i.e. random walk, continuous ingest).
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. Starting with 2.0, these tests are run using the <a
href="https://github.com/apache/accumulo-testing";>Accumulo Testing repo</a>.
See the <a
href="https://github.com/apache/accumulo-testing/blob/main/README.md";>README.md</a>
-for more information. Before 2.0, these tests are found in Accumulo tarball
at <code class="language-plaintext
highlighter-rouge">test/system/randomwalk</code> and
-<code class="language-plaintext
highlighter-rouge">test/system/continuous</code> which include instructions on
how to run the tests.</p>
- </li>
+ <li>Run only Accumulo’s unit tests and build the software using <code
class="language-plaintext highlighter-rouge">mvn package</code></li>
+ <li>Run Accumulo’s unit and integration tests using <code
class="language-plaintext highlighter-rouge">mvn verify</code></li>
+ <li>Build the <a href="https://github.com/apache/accumulo-examples";>Accumulo
Examples</a> repo using the release candidate by updating the
+<code class="language-plaintext highlighter-rouge">accumulo.version</code>
property in the <code class="language-plaintext
highlighter-rouge">pom.xml</code> and using the staging repo. Also, run the
+unit/integration tests using <code class="language-plaintext
highlighter-rouge">mvn verify</code>.</li>
+ <li>Run Accumulo’s distributed tests (i.e. random walk, continuous ingest).
These tests are intended
+to be run for hours or days, optionally injecting faults into the system
through “agitation”.
+These tests simulate behaviors that can occur on a real deployment. Starting
with 2.0, these tests
+are run using the <a
href="https://github.com/apache/accumulo-testing";>Accumulo Testing repo</a>.
See the <a
href="https://github.com/apache/accumulo-testing/blob/main/README.md";>README.md</a>
for more
+information. Before 2.0, these tests are found in Accumulo tarball at <code
class="language-plaintext highlighter-rouge">test/system/randomwalk</code> and
+<code class="language-plaintext
highlighter-rouge">test/system/continuous</code> which include instructions on
how to run the tests.</li>
</ul>
<h2 id="project-testing-goals">Project testing goals</h2>
-<p>While contributors do not need perform all tests, there should a minimum
amount of testing done by the project as whole before a release is made.</p>
+<p>While contributors do not need perform all tests, there should a minimum
amount of testing done by
+the project as whole before a release. The testing that the developers do are
documented in the
+release notes for that release.</p>
-<p>Testing for an Accumulo release includes a few steps that a developer may
take without a Hadoop cluster and several that require a working cluster. For
minor releases,
-the tests which run on a Hadoop cluster are recommended to be completed but
are not required. Running even a reduced set of tests against real hardware is
always encouraged
-even if the full test suite (in breadth of nodes or duration) is not executed.
If PMC members do not believe adequate testing was performed for the sake of
making the proposed
-release, the release should be vetoed via the normal voting process. New major
releases are expected to run a full test suite.</p>
+<p>Testing for an Accumulo release includes a few steps that a developer may
take without a Hadoop
+cluster and several that require a working cluster. For minor releases, the
tests which run on a
+Hadoop cluster are recommended to be completed but are not required. Running
even a reduced set of
+tests against real hardware is always encouraged even if the full test suite
(in breadth of nodes or
+duration) is not executed. New major releases are expected to receive more
comprehensive testing,
+because they contain a greater number of changes and require more vetting.</p>
+
+<p>If PMC members do not believe adequate testing was performed for the sake
of making the proposed
+release, they may vote <code class="language-plaintext
highlighter-rouge">-0</code> or <code class="language-plaintext
highlighter-rouge">-1</code> on that release and are encouraged to assist with
testing the
+release to their satisfaction.</p>
<h3 id="stand-alone">Stand alone</h3>
-<p>The following steps can be taken without having an underlying cluster. They
SHOULD be handled with each Hadoop profile available for a given release
version. To activate an alternative profile specify e.g. “-Dhadoop.profile=2”
for the Hadoop 2 profile on the Maven commandline. Some older versions of
Accumulo referred to Hadoop profiles differently; see the README that came with
said versions for details on building against different Hadoop versions.</p>
+<p>The following steps can be taken without having an underlying cluster. They
should be handled with
+each Hadoop profile available for a given release version. To activate an
alternative profile
+specify e.g. <code class="language-plaintext
highlighter-rouge">-Dhadoop.profile=2</code> for the Hadoop 2 profile on the
Maven commandline. Some older
+versions of Accumulo referred to Hadoop profiles differently; see the README
that came with said
+versions for details on building against different Hadoop versions, or its
release notes.</p>
-<ol>
- <li>All JUnit tests must pass. This should be a requirement of any patch so
it should never be an issue of the codebase.
- - Use “mvn package” to run against the default profile of a particular
release
- - Use “mvn -Dhadoop.profile=2 package” to test against the Hadoop 2
profile on e.g. 1.4 or 1.5
- - Use “mvn -Dhadoop.profile=1 package” to test against the Hadoop 1
profile on e.g. 1.6 or later
+<ul>
+ <li>All JUnit tests should pass. This should be a requirement of any patch
so it should never be an
+issue during a release.
<ul>
- <li>Analyze output of static analysis tools like Findbugs and PMD.</li>
- <li>For versions 1.6 and later, all functional tests must pass via the
Maven failsafe plugin.
- <ul>
- <li>Use “mvn verify” to run against the default profile of a
particular release</li>
- <li>Use “mvn -Dhadoop.profile=1 verify” to run the functional tests
against the Hadoop 1 profile</li>
- </ul>
- </li>
+ <li>Use <code class="language-plaintext highlighter-rouge">mvn
package</code> to run against the default profile of a particular release</li>
+ <li>Use <code class="language-plaintext highlighter-rouge">mvn
-Dhadoop.profile=2 package</code> to test against the Hadoop 2 profile (not
applicable to
+all versions)</li>
</ul>
</li>
-</ol>
+ <li>Analyze output of static analysis tools like spotbugs and PMD.</li>
+ <li>For versions 1.6 and later, all integration tests should pass via the
Maven failsafe plugin.
+ <ul>
+ <li>Use <code class="language-plaintext highlighter-rouge">mvn
verify</code> to run against the default profile of a particular release</li>
+ <li>Use <code class="language-plaintext highlighter-rouge">mvn
-Dhadoop.profile=2 verify</code> to run the tests against the Hadoop 2 profile
(not
+applicable to all versions)</li>
+ </ul>
+ </li>
+</ul>
<h3 id="cluster-based">Cluster based</h3>
-<p>The following tests require a Hadoop cluster running a minimum of HDFS,
MapReduce, and ZooKeeper. The cluster MAY have any number of worker nodes; it
can even be a single node in pseudo-distributed mode. A cluster with multiple
tablet servers SHOULD be used so that more of the code base will be exercised.
For the purposes of release testing, you should note the number of nodes and
versions used. See the Releasing section for more details.</p>
+<p>The following tests require a Hadoop cluster running a minimum of HDFS,
MapReduce, and ZooKeeper.
+The cluster may have any number of worker nodes; it can even be a single node
in pseudo-distributed
+mode. A cluster with multiple tablet servers should be used so that more of
the code base will be
+exercised. For the purposes of release testing, you should note the number of
nodes and versions
+used. See the Releasing section for more details. These are only example of
cluster tests. You may
+run more or less tests. Information about these can be found in the <a
href="https://github.com/apache/accumulo-testing";>Accumulo Testing repo</a>.</p>
-<ol>
- <li>For versions prior to 1.6, all functional tests must complete
successfully.
- - See $ACCUMULO_HOME/test/system/auto/README for details on running the
functional tests.
- <ul>
- <li>Two 24-hour periods of the LongClean module of the RandomWalk test
need to be run successfully. One of them must use agitation and the other
should not.
- <ul>
- <li>See $ACCUMULO_HOME/test/system/randomwalk/README for details on
running the LongClean module.</li>
- </ul>
- </li>
- <li>Two 24-hour periods of the continuous ingest test must be validated
successfully. One test period must use agitation and the other should not.
- <ul>
- <li>See $ACCUMULO_HOME/test/system/continuous/README for details on
running and verifying the continuous ingest test.</li>
- </ul>
- </li>
- <li>Two 72-hour periods of continuous ingest must run. One test period
must use agitation and the other should not. No validation is necessary but the
cluster should be checked to ensure it is still functional.</li>
- </ul>
- </li>
-</ol>
+<ul>
+ <li>Two 24-hour periods of the <code class="language-plaintext
highlighter-rouge">LongClean</code> module of the RandomWalk test without
unexpected errors,
+one with agitation, and one without</li>
+ <li>Two 24-hour periods of the continuous ingest test, with successful
verification, one with
+agitation and one without</li>
+ <li>A 24-hour period of the bulk continuous ingest test, with successful
verification</li>
+ <li>A 72-hour period of continuous ingest without verification, but check
the logs for any errors
+and ensure the cluster is still functional</li>
+</ul>
<h2 id="foundation-level-requirements">Foundation Level Requirements</h2>
-<p>The ASF requires that all artifacts in a release are cryptographically
signed and distributed with hashes.</p>
+<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
class="language-plaintext highlighter-rouge">sha1sum</code>, <code
class="language-plaintext highlighter-rouge">md5sum</code>).</p>
+<p>PGP/GPG 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 (e.g. <code class="language-plaintext
highlighter-rouge">gpg --import KEYS; gpg --verify *.asc</code>). Hashes can be
verified
+using the appropriate command (e.g. <code class="language-plaintext
highlighter-rouge">sha512sum -c *.sha512</code>)</p>
-<p>An Apache release must contain a source-only artifact. This is the official
release artifact. While a release of
-an 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>An Apache release must contain a source-only artifact. This is the official
release artifact. While
+a release of an 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>
+<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>
<p>The following are the aforementioned Foundation-level documents provided
for reference:</p>
@@ -258,36 +264,39 @@ as they are only used for testing the software and not
running it.</p>
<h2 id="apache-software-license-application">Apache Software License
Application</h2>
-<p>Application of the Apache Software License v2 consists of the following
steps on each artifact in a release. It’s
-important to remember that for artifacts that contain other artifacts (e.g. a
tarball that contains JAR files or
-an RPM which contains JAR files), both the tarball, RPM and JAR files are
subject to the following roles.</p>
+<p>Application of the Apache Software License v2 consists of the following
steps on each artifact in a
+release. It’s important to remember that for artifacts that contain other
artifacts (e.g. a tarball
+that contains JAR files), both the tarball and JAR files are subject to the
following rules.</p>
-<p>The difficulty in verifying each artifact is that, often times, each
artifact requires a different LICENSE and NOTICE
-file. For example, the Accumulo binary tarball must contain appropriate
LICENSE and NOTICE files considering the bundled
-jar files in <code class="language-plaintext highlighter-rouge">lib/</code>.
The Accumulo source tarball would not contain these same contents in the
LICENSE and NOTICE files
-as it does not contain those same JARs.</p>
+<p>The difficulty in verifying each artifact is that, often times, each
artifact requires a different
+LICENSE and NOTICE file. For example, the Accumulo binary tarball must contain
appropriate LICENSE
+and NOTICE files considering the bundled jar files in <code
class="language-plaintext highlighter-rouge">lib/</code>. The Accumulo source
tarball would not
+contain these same contents in the LICENSE and NOTICE files as it does not
contain those same JARs.</p>
<h3 id="license-file">LICENSE file</h3>
-<p>The LICENSE file should be present at the top-level of the artifact. This
file should be explicitly named <code class="language-plaintext
highlighter-rouge">LICENSE</code>,
-however <code class="language-plaintext highlighter-rouge">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>
+<p>The LICENSE file should be present at the top-level of the artifact. This
file should be explicitly
+named <code class="language-plaintext highlighter-rouge">LICENSE</code>. 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>
<h3 id="notice-file">NOTICE file</h3>
-<p>The NOTICE file should be present at the top-level of the artifact beside
the LICENSE file. This file should be explicitly
-name <code class="language-plaintext highlighter-rouge">NOTICE</code>, while
<code class="language-plaintext highlighter-rouge">NOTICE.txt</code> is also
acceptable but not preferred. This file contains the copyright notice for
-the artifact being released. As a reminder, the copyright is held by the
Apache Software Foundation, not the individual
-project.</p>
-
-<p>The second purpose this file serves is to distribute third-party notices
from dependent software. Specifically, other code
-which is licensed with the ASLv2 may also contain a NOTICE file. If such an
artifact which contains a NOTICE file is
-contained in artifact being verified for releases, the contents of the
contained artifact’s NOTICE file should be appended
-to this artifact’s NOTICE file. For example, Accumulo bundles the Apache
Thrift libthrift JAR file which also have its
-own NOTICE file. The contents of the Apache Thrift NOTICE file should be
included within Accumulo’s NOTICE file.</p>
+<p>The NOTICE file should be present at the top-level of the artifact beside
the LICENSE file. This
+file should be explicitly named <code class="language-plaintext
highlighter-rouge">NOTICE</code>. This file contains the copyright notice for
the artifact
+being released. As a reminder, the copyright is held by the Apache Software
Foundation, not the
+individual project.</p>
+
+<p>The purpose this file serves is to distribute required third-party
copyright notices from dependent
+software. Specifically, other code which is licensed with the ASLv2 may also
contain a NOTICE file.
+If such an artifact which contains a NOTICE file is contained in artifact
being verified for
+releases, the contents of the contained artifact’s NOTICE file should be
appended to this artifact’s
+NOTICE file. For example, Accumulo bundles the Apache Thrift libthrift JAR
file which also have its
+own NOTICE file. The required contents of the Apache Thrift NOTICE file should
be included within
+Accumulo’s NOTICE file. Redundant notices, such as duplicate entries for the
Apache Software
+Foundation should be omitted. This file should only contain required notices,
and nothing else.</p>
</div>
diff --git a/output/feed.xml b/output/feed.xml
index da0a316e..58dd0aea 100644
--- a/output/feed.xml
+++ b/output/feed.xml
@@ -6,8 +6,8 @@
</description>
<link>https://accumulo.apache.org/</link>
<atom:link href="https://accumulo.apache.org/feed.xml"; rel="self"
type="application/rss+xml"/>
- <pubDate>Mon, 24 Oct 2022 15:27:42 +0000</pubDate>
- <lastBuildDate>Mon, 24 Oct 2022 15:27:42 +0000</lastBuildDate>
+ <pubDate>Tue, 25 Oct 2022 16:20:48 +0000</pubDate>
+ <lastBuildDate>Tue, 25 Oct 2022 16:20:48 +0000</lastBuildDate>
<generator>Jekyll v4.2.0</generator>
