Author: hwright
Date: Tue Jun 28 13:56:02 2011
New Revision: 1140622
URL: http://svn.apache.org/viewvc?rev=1140622&view=rev
Log:
Release docs: Create a new section about "Creating a release" and include
the section on signing releases in it. Update to reference various ASF docs
and to reflect our current procedures.
* publish/docs/community-guide/releasing.part.html
(preface): Add a paragraph referencing ASF docs.
(release-creating): New section.
(tarball-signing): Fold into release-creating, and add a couple of paragraphs
about why signing releases is important.
Modified:
subversion/site/publish/docs/community-guide/releasing.part.html
Modified: subversion/site/publish/docs/community-guide/releasing.part.html
URL:
http://svn.apache.org/viewvc/subversion/site/publish/docs/community-guide/releasing.part.html?rev=1140622&r1=1140621&r2=1140622&view=diff
==============================================================================
--- subversion/site/publish/docs/community-guide/releasing.part.html (original)
+++ subversion/site/publish/docs/community-guide/releasing.part.html Tue Jun 28
13:56:02 2011
@@ -26,6 +26,12 @@ This script can be used to perform most
in the release process. Run it with the <tt>-h</tt> option to get more
information.</p>
+<p>In addition to the following project-specific guidelines, aspiring release
+managers may also want to read up on the general
+<a href="http://www.apache.org/dev/release.html";>Apache release policies</a>.
+They can seem a bit patchwork at times, but give a good idea of general
+best practice and how Subversion fits in the larger ASF ecosystem.</p>
+
<div class="h2" id="release-process">
<h2>Subversion release process
<a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE"
-->#release-process"
@@ -574,28 +580,63 @@ voting, are always kept on the main rele
</div> <!-- release-process -->
+<div class="h2" id="release-creating">
+<h2>Creating a Subversion release
+ <a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE"
-->#release-creating"
+ title="Link to this section">¶</a>
+</h2>
-<div class="h2" id="tarball-signing">
-<h2>Signing source distribution packages (a.k.a tarballs)
+<div class="h3" id="tarball-signing">
+<h3>Signing source distribution packages (a.k.a tarballs)
<a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE"
-->#tarball-signing"
title="Link to this section">¶</a>
-</h2>
+</h3>
-<p>Before a release or release candidate is officially made public, it is
-made available in a temporary location for committers to test and sign.
-The point is to have the tarballs tested on more systems than just that of the
-person who rolled the release. When there are three signatures from full
-committers for each of the <tt>.tar.bz2</tt>, <tt>.tar.gz</tt> and
-<tt>.zip</tt> files, the release (candidate) can go public.</p>
+<p>Because Subversion releases are distributed through the
+<a href="http://www.apache.org/dev/mirrors.html";>ASF mirror network</a>, it
+is important that end-users be able to verify the authenticity of the source
+code packages they download. Checksums are sufficient to detect corruption
+in the download process, but to prevent a malicious individual or mirror
+operator from distributing replacement packages, each source code package
+must be
+<a href="http://www.apache.org/dev/release-signing.html";>cryptographically
+signed</a> by members of the Subversion PMC. These
+signatures are done using each committer's private PGP key, and are then
+published with the release so that end users can verify the integrity of the
+downloaded packages.</p>
+
+<p>When creating the initial set of tarballs, the release manager will also
+create the first set of signatures. While the tarballs themselves may be
+built on <tt>people.apache.org</tt>, it is important that the signatures are
+<em>not</em> generated there. Signing tarballs requires a private key, and
+storing private keys on ASF hardware is <em>strongly discouraged</em>. After
+signing the tarballs (using the process below) the release manager should
+upload the signatures to the preliminary distribution location, and place them
+in the same directory as the tarballs.</p>
+
+<p>Before a release is officially made public, it must receive three +1 votes
+from members of the Subversion PMC. In addition, as a matter of project
+policy, we require testing and signatures from PMC members on <em>each</em>
+of the major platforms we support: Windows and *nix. Members of the PMC,
+as well as enthusiastic community members are encourages to download the
+tarballs from the preliminary distribution location, run the tests, and then
+provide their signatures. The public keys for these signatures should be
+included in the ASF LDAP instance through
+<a href="https://id.apache.org/";>id.apache.org</a>. (A list of the
+<a href="https://people.apache.org/keys/group/subversion-pmc.asc";>current
+public keys</a> for members of the Subversion PMC is autogenerated from LDAP
+each day.)</p>
<p>Signing a tarball means that you assert certain things about it. When
-sending your signature (see below), indicate in the mail what steps
-you've taken to verify that the tarball is correct. Running
-<tt>make check</tt> over all RA layers and FS backends is a good idea,
-as well as building and testing the bindings.</p>
-
-<p>After having extracted and tested the tarball, you should sign it using
-<a href="http://www.gnupg.org";>gpg</a>. To do so, use a command like:</p>
+announcing your signature, indicate in the mail what steps you've taken to
+verify that the tarball is correct, such as verifying the contents against
+the proper tag in the repository. Running <tt>make check</tt> over all RA
+layers and FS backends is also a good idea, as well as building and testing
+the bindings.</p>
+
+<p>After having extracted and tested the tarball, you should sign by creating
+an armored detached signature using <a href="http://www.gnupg.org";>gpg</a>.
+To do so, use a command like:</p>
<pre>
gpg -ba subversion-1.3.0-rc4.tar.bz2
@@ -618,7 +659,7 @@ to download and test it separately. The
<p>The resulting file should be identical to the file generated by the
release manager, and thus can be signed as described above.
-To verify that the files are identical, you may use either the MD5 checksums
+To verify that the files are identical, you may use either the SHA1 checksums
or the release manager's signature, both of which should be provided with the
tarballs.</p>
@@ -629,6 +670,8 @@ manager.</p>
</div> <!-- tarball-signing -->
+</div> <!-- release-creating -->
+
<div class="h2" id="custom-releases">
<h2>Custom releases
