svn commit: r554684 - /httpd/site/trunk/xdocs/dev/release.xml

[wr...@apache.org]

Author: wrowe
Date: Mon Jul  9 08:36:42 2007
New Revision: 554684

URL: http://svn.apache.org/viewvc?view=rev&rev=554684
Log:
Slight wordsmithing.

Modified:
    httpd/site/trunk/xdocs/dev/release.xml

Modified: httpd/site/trunk/xdocs/dev/release.xml
URL: http://svn.apache.org/viewvc/httpd/site/trunk/xdocs/dev/release.xml?view=diff&rev=554684&r1=554683&r2=554684
==============================================================================
--- httpd/site/trunk/xdocs/dev/release.xml (original)
+++ httpd/site/trunk/xdocs/dev/release.xml Mon Jul  9 08:36:42 2007
@@ -106,8 +106,8 @@
 </section>
 
 <section><title>How to do a release?</title>
-<p>Once the tree has been suitably tested by the RM and any other
-interested parties, they should "roll" the release.</p>
+<p>Once the tree has been suitably tested by the RM and any other interested 
+parties, they should "roll" a candidate tarball for potential release.</p>
 
 <p>Key points:</p>
 <ul>
@@ -117,13 +117,18 @@
 <li>Copy the generated release tarballs and signatures to
 people.apache.org:/www/httpd.apache.org/dev/dist</li>
 <li>Email dev@httpd.apache.org, current-testers@httpd.apache.org and
-stable-testers@httpd.apache.org to inform them of the release.</li>
+stable-testers@httpd.apache.org with a [VOTE] Release X.Y.Z to call for
+testing and votes on this candidate.</li>
 </ul>
 </section>
 
 <section><title>What can I call this release?</title>
-<p>At this point, the release is an alpha.  The Apache HTTP Server Project
-has three classifications for its releases:</p>
+<p>At this point, this tarball/archive is not yet a release.
+
+<p>Based on the communities confidence in the code, the next step is
+to issue a release vote as alpha, beta or general availability (GA)
+candidate.  The Apache HTTP Server Project has three classifications 
+for its releases:</p>
 
 <ul>
 <li>Alpha</li>
@@ -132,34 +137,46 @@
 </ul>
 
 <p>Alpha indicates that the release is not meant for mainstream usage or
-may have serious problems that prohibits its use.  When a release is
-initially created, it automatically becomes alpha quality.</p>
+may have serious problems that prohibits its use.  The initial releases
+off of the x.{odd}.z development branches are considered alpha quality.</p>
 
-<p>Beta indicates that at least three committers have voted positively
-for beta status and there were more positive than negative votes for
-beta designation.  This indicates that it is expected to compile and
-perform basic tasks.  However, there may be problems with this release
-that prohibit its widespread adoption.</p>
-
-<p>General Availability (GA) indicates that at least three committers
-have voted positively for GA status and that there were more positive
-than negative votes for GA designation.  This release is recommended
-for production usage.</p>
+<p>Beta indicates that the x.{odd}.z development branch is nearing
+completion and will soon ship as a x.{even}.0 GA release.  This indicates
+that it is expected to compile and perform basic tasks.  However, there 
+may be problems with this release that inhibit its widespread adoption.</p>
+
+<p>General Availability (GA) indicates that this release is the best
+available version and is recommended for all usage.  It also indicates
+that this release replaces all previous GA versions, and it's interfaces
+should remain stable throughout the life of this x.y version.  (Those
+interfaces that are in flux are designated <i>experimental</i>.)</p>
+
+<p>Finally, remember version numbers are cheap.  If x.y.13 is retracted
+due to a flaw or prior veto or simply because of 'one more change' to add
+to this next release, then the RM should designate x.y.14.  Don't attempt 
+to overload an earlier tarball with additional changes, simply keep moving.</p>
 </section>
 
 <section><title>Who can vote?</title>
+<p>For the ASF to release the prepared tarball/archive, at least three 
+project members must vote affirmatively for release, and there must be more 
+positive than negative votes for the release.  There is no 'veto' to a
+release vote.  A previous veto of specific code can and should be called 
+out to the RM if it was not honored, and it's the RM's decision to determine
+that the veto included a justification and therefore retract the vote.  A new 
+tarball release candidate should be rolled without the offending code if this
+is the case.</p>
+
 <p>Non-committers may cast a vote for a release's quality.  In fact,
 this is extremely encouraged as it provides much-needed feedback to
 the community about the release's quality.  However, only binding
 votes casted by committers count towards the designation.</p>
 
-<p>Note that no one may veto a release.  Releases may not receive a
-designation level if a problem is found that inhibits proper
-functionality.  The group may (implicitly or explicitly) revoke all votes
-on a release if there is a problem.  However, if there is a -1 vote for
-a particular designation and there are greater than 3 positive votes
-and more positive than negative votes (i.e. majority consensus), the
-appropriate designation is conferred upon the release.</p>
+<p>Finally, note that votes are on <i>source code</i> tarballs, and only the
+source code is authoritative.  Binaries, while helpful, are considered
+other artifacts and must be generated from the exact source code contained
+in the release.  If a patch is unavoidable for a specific platform, the
+applicable patches MUST be made available alongside the platform binaries.</p>
 </section>
 
 <section><title>How do we make it public?</title>