You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by fi...@apache.org on 2011/09/10 04:12:29 UTC
svn commit: r1167435 - in /httpd/site/trunk: docs/dev/release.html
xdocs/dev/release.xml
Author: fielding
Date: Sat Sep 10 02:12:29 2011
New Revision: 1167435
URL: http://svn.apache.org/viewvc?rev=1167435&view=rev
Log:
I am so friggin sick and tired of this bullshit release documentation
being used as evidence that our true bylaws don't apply to RM decisions.
Fix that.
Modified:
httpd/site/trunk/docs/dev/release.html
httpd/site/trunk/xdocs/dev/release.xml
Modified: httpd/site/trunk/docs/dev/release.html
URL: http://svn.apache.org/viewvc/httpd/site/trunk/docs/dev/release.html?rev=1167435&r1=1167434&r2=1167435&view=diff
==============================================================================
--- httpd/site/trunk/docs/dev/release.html [utf-8] (original)
+++ httpd/site/trunk/docs/dev/release.html [utf-8] Sat Sep 10 02:12:29 2011
@@ -74,8 +74,8 @@ href="/info/">Miscellaneous</a></b></p>
<blockquote>
<p>This document describes the general release policies used by the
Apache HTTP Server Project to create releases of httpd-2.2 (the current
-Apache 2.2 branch). As described herein, this policy is not set in stone
-and may be adjusted by the Release Manager.</p>
+Apache 2.2 branch). Aside from the voting guidelines, this policy
+may be adjusted by the Release Manager.</p>
<p>With the introduction of Apache 2.1, the Apache httpd project has
adopted an odd-even release strategy, where development happens with
alpha and beta releases assigned an odd-numbered minor version, and its
@@ -99,9 +99,9 @@ were followed by 2.1.7-beta through 2.1.
<p>Technically, anyone can make a release of the source code due to the
<a href="http://www.apache.org/licenses/">Apache Software License</a>.
However, only members of the Apache HTTP Server Project (committers)
-can make a release designated with Apache. Other people must
-call their release something other than "Apache" unless they obtain
-written permission from the Apache Software Foundation.</p>
+can make a release designated as Apache HTTP Server (httpd). Other
+people must call their release something other than "Apache" unless
+they obtain written permission from the Apache Software Foundation.</p>
<p>Following our official release policies, we will only accept release
binaries from members of the Apache HTTP Server Project for inclusion on our
website. This ensures that our binaries can be supported by members of
@@ -120,14 +120,18 @@ post them on our website.</p>
</tr>
<tr><td>
<blockquote>
-<p>The release is coordinated by the Release Manager (hereafter, abbreviated
-as RM). Since this job requires coordination of the development community
-(and access to subversion), only committers to the project can be RM. However,
-there is no set RM. Any committer may perform a release at any time. In
-order to facilitate communication, it is deemed nice to alert the
-community with your planned release schedule before executing the
-release. A release should only be made when there is a plan to publicly
-release it. (A release must not be made only for private distribution).</p>
+<p>The release is coordinated by a Release Manager (hereafter, abbreviated
+as RM). Since this job requires trust, coordination of the development
+community, and access to subversion, only committers to the project can be RM.
+However, there is no set RM, and more than one RM can be active at a time.
+Any committer may create a release candidate, provided that it is based on
+a releasable (non-vetoed) tag of our current subversion repository
+corresponding to the target version number. In order to facilitate
+communication, it is deemed nice to alert the community to your planned
+release schedule before creating the release candidate, since some other
+folks may be on the verge of committing an important change (or backing out an
+error). A release candidate should only be made when there is an intention
+to propose it for a vote on public release. There are no "private" releases at Apache.</p>
</blockquote>
</td></tr>
</table>
@@ -160,16 +164,24 @@ release fares better than non-coordinate
</tr>
<tr><td>
<blockquote>
-<p>It is our convention to indicate <i>showstoppers</i> in the STATUS
-file in the repository. A showstopper entry does not automatically
-imply that a release can not be made. As the RM has final authority
-on what makes it into a release, they can choose to ignore the entries.
-An item being denoted as a <i>showstopper</i> indicates that the group
-has come to a consensus that no further releases can be made until the
-entry is resolved. These items may be bugs, outstanding vetos that have
-not yet been resolved, or enhancements that must make it into the
+<p>Generally speaking, when some useful changes have been applied since
+the last release and there are no showstoppers left to be resolved.
+It is our convention to indicate <i>showstoppers</i> in the STATUS
+file in the repository. A showstopper entry does not imply that a release
+cannot be made -- it is more of an indication of current project consensus
+and a reminder of what fixes are on the critical path. Each RM gets to
+choose when to cut a release candidate based on the current content of
+subversion. The entire PMC gets to decide whether or not that candidate
+deserves to be released.</p>
+<p>An item being denoted in STATUS as a <i>showstopper</i> indicates that
+someone believes the issue must be resolved before the next release,
+and the RM is going to hold off until it is resolved or moved out of
+the showstopper category. These items may be bugs, outstanding vetos
+that have not yet been resolved, or enhancements that must make it into the
release. Note that the RM may also add showstopper entries to indicate
-what issues must be resolved before they intend to create a release.</p>
+what issues must be resolved before they personally are willing to cut
+a release candidate, though they cannot prevent others from taking on
+the RM job and proposing a release candidate of their own.</p>
</blockquote>
</td></tr>
</table>
@@ -183,37 +195,33 @@ what issues must be resolved before they
</tr>
<tr><td>
<blockquote>
-<p>Regarding what makes it into a release, the RM is the unquestioned
-authority. No one can contest what makes it into the release. The
-community will judge the release's quality after it has been issued,
-but the community can not force the RM to include a feature that they
-feel uncomfortable adding. Remember that this document is only a
-guideline to the community and future RMs - each RM may run a release
-in a different way. If you don't like what an RM is doing, start
-preparing for your own competing release.</p>
- </blockquote>
- </td></tr>
-</table>
- <table border="0" cellspacing="0" cellpadding="2" width="100%">
- <tr>
- <td bgcolor="#525D76">
- <font color="#ffffff" face="arial,helvetica,sanserif">
- <strong>How does an impending release affect development?</strong>
- </font>
- </td>
- </tr>
- <tr><td>
- <blockquote>
-<p>It can not. Let's repeat that: <b>an impending release can not affect
-development of the project</b>. It is the RM's responsibility to identify
-what changes should make it into the release. The RM may have an
-intermediate tag, so the RM can merge in or reject changes as they are
-committed to the repository's HEAD.</p>
-<p>Committers <i>may</i> voluntarily refrain from committing patches if
-they wish to ease the burden on the RM, but they are under
-<font color="red">no</font> obligation to do so. This is one reason why we
-recommend that the RMs have plenty of time on their hands - they may have to
-deal with a rapidly changing target. It's not an easy job.</p>
+<p>The only power held by the RM is the right to determine when the
+current content of subversion is worth their own effort in cutting
+a release candidate. The only thing the RM has authority over is the
+building of a source package, based on the contents of our subversion,
+that can then be put up for vote. They can decide what snapshot revision
+to tag for a candidate. They can decide to branch early and build candidates
+based on the branch rather than a more active development tree, but they
+cannot prevent others from working on that branch as well.
+They can also decide not to build anything at all. They can
+do all sorts of organizational support, advocacy, pleading, or
+whatever in order to encourage the rest of the project committers to
+apply changes, test the candidate, vote for things under issue, etc.</p>
+<p>The RM is not a dictator (benevolent or not). They do not have the
+right to pick apart or select any variation of the product they might like
+to release: it has to be a specific tag or revision (moment in time) that
+is present in our subversion and applicable to the version number
+targeted for the release. If there is something they don't like in
+the tree, then they have the same right as other PMC members to change
+or veto that code first, make the change to subversion, and then build
+the release candidate. Likewise, the RM cannot include in the candidate
+any change that has been vetoed by others, and their candidate cannot
+be released if it contains any changes that have been vetoed
+since it was built. The RM has the right to kill their own candidate
+if they learn something during the release process that they think,
+for whatever reason, causes the build to be unreleasable. But the
+RM can't stop anyone else on the PMC from taking the same candidate
+and calling for its release under their own management as RM.</p>
</blockquote>
</td></tr>
</table>
@@ -233,15 +241,15 @@ The release candidate should pass all of
it official, and certainly avoid new regressions (tests that previously
passed, and now fail).</p>
<p>Another good idea is to coordinate running a candidate on apache.org for
-a period of time. This will require coordination with the current
-maintainers of apache.org's httpd instance. In the past, the group has
-liked to see approximately 48-72 hours of usage in production to certify
-that the release is functional in the real world. Note that some committers
-may choose to not vote on a release until feedback has been gathered from the
-apache.org instance running the release. This is not a requirement (each
-committer is free to come up with their own personal voting guidelines),
-but it produces a feeling of confidence in the release that it will not
-be a <i>dud</i>.</p>
+a period of time. This will require coordination with the infrastructure
+team.
+In the past, the group has liked to see approximately 48-72 hours of
+usage in production to certify that the release is functional in the real
+world. Note that some committers may choose to not vote on a release until
+feedback has been gathered from the apache.org instance running the release.
+This is not a requirement (each committer is free to come up with their own
+personal voting guidelines), but it produces a feeling of confidence in the
+release that it will not be a <i>dud</i>.</p>
</blockquote>
</td></tr>
</table>
@@ -330,18 +338,17 @@ to overload an earlier tarball with addi
</tr>
<tr><td>
<blockquote>
-<p>For the ASF to release the prepared tarball/archive, at least three
+<p>For the ASF to release the candidate 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
+out to the RM if it was mistakenly included. 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>
+votes cast by PMC members count towards the designation.</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
Modified: httpd/site/trunk/xdocs/dev/release.xml
URL: http://svn.apache.org/viewvc/httpd/site/trunk/xdocs/dev/release.xml?rev=1167435&r1=1167434&r2=1167435&view=diff
==============================================================================
--- httpd/site/trunk/xdocs/dev/release.xml [utf-8] (original)
+++ httpd/site/trunk/xdocs/dev/release.xml [utf-8] Sat Sep 10 02:12:29 2011
@@ -9,8 +9,8 @@
<section><title>Introduction</title>
<p>This document describes the general release policies used by the
Apache HTTP Server Project to create releases of httpd-2.2 (the current
-Apache 2.2 branch). As described herein, this policy is not set in stone
-and may be adjusted by the Release Manager.</p>
+Apache 2.2 branch). Aside from the voting guidelines, this policy
+may be adjusted by the Release Manager.</p>
<p>With the introduction of Apache 2.1, the Apache httpd project has
adopted an odd-even release strategy, where development happens with
@@ -25,9 +25,9 @@ were followed by 2.1.7-beta through 2.1.
<p>Technically, anyone can make a release of the source code due to the
<a href="http://www.apache.org/licenses/">Apache Software License</a>.
However, only members of the Apache HTTP Server Project (committers)
-can make a release designated with Apache. Other people must
-call their release something other than "Apache" unless they obtain
-written permission from the Apache Software Foundation.</p>
+can make a release designated as Apache HTTP Server (httpd). Other
+people must call their release something other than "Apache" unless
+they obtain written permission from the Apache Software Foundation.</p>
<p>Following our official release policies, we will only accept release
binaries from members of the Apache HTTP Server Project for inclusion on our
@@ -37,14 +37,18 @@ post them on our website.</p>
</section>
<section><title>Who is in charge of a release?</title>
-<p>The release is coordinated by the Release Manager (hereafter, abbreviated
-as RM). Since this job requires coordination of the development community
-(and access to subversion), only committers to the project can be RM. However,
-there is no set RM. Any committer may perform a release at any time. In
-order to facilitate communication, it is deemed nice to alert the
-community with your planned release schedule before executing the
-release. A release should only be made when there is a plan to publicly
-release it. (A release must not be made only for private distribution).</p>
+<p>The release is coordinated by a Release Manager (hereafter, abbreviated
+as RM). Since this job requires trust, coordination of the development
+community, and access to subversion, only committers to the project can be RM.
+However, there is no set RM, and more than one RM can be active at a time.
+Any committer may create a release candidate, provided that it is based on
+a releasable (non-vetoed) tag of our current subversion repository
+corresponding to the target version number. In order to facilitate
+communication, it is deemed nice to alert the community to your planned
+release schedule before creating the release candidate, since some other
+folks may be on the verge of committing an important change (or backing out an
+error). A release candidate should only be made when there is an intention
+to propose it for a vote on public release. There are no "private" releases at Apache.</p>
</section>
<section><title>Who may make a good candidate for an RM?</title>
@@ -57,41 +61,56 @@ release fares better than non-coordinate
</section>
<section><title>When do I know if it is a good time to release?</title>
-<p>It is our convention to indicate <i>showstoppers</i> in the STATUS
-file in the repository. A showstopper entry does not automatically
-imply that a release can not be made. As the RM has final authority
-on what makes it into a release, they can choose to ignore the entries.
-An item being denoted as a <i>showstopper</i> indicates that the group
-has come to a consensus that no further releases can be made until the
-entry is resolved. These items may be bugs, outstanding vetos that have
-not yet been resolved, or enhancements that must make it into the
+<p>Generally speaking, when some useful changes have been applied since
+the last release and there are no showstoppers left to be resolved.
+It is our convention to indicate <i>showstoppers</i> in the STATUS
+file in the repository. A showstopper entry does not imply that a release
+cannot be made -- it is more of an indication of current project consensus
+and a reminder of what fixes are on the critical path. Each RM gets to
+choose when to cut a release candidate based on the current content of
+subversion. The entire PMC gets to decide whether or not that candidate
+deserves to be released.</p>
+
+<p>An item being denoted in STATUS as a <i>showstopper</i> indicates that
+someone believes the issue must be resolved before the next release,
+and the RM is going to hold off until it is resolved or moved out of
+the showstopper category. These items may be bugs, outstanding vetos
+that have not yet been resolved, or enhancements that must make it into the
release. Note that the RM may also add showstopper entries to indicate
-what issues must be resolved before they intend to create a release.</p>
+what issues must be resolved before they personally are willing to cut
+a release candidate, though they cannot prevent others from taking on
+the RM job and proposing a release candidate of their own.</p>
</section>
<section><title>What power does the RM yield?</title>
-<p>Regarding what makes it into a release, the RM is the unquestioned
-authority. No one can contest what makes it into the release. The
-community will judge the release's quality after it has been issued,
-but the community can not force the RM to include a feature that they
-feel uncomfortable adding. Remember that this document is only a
-guideline to the community and future RMs - each RM may run a release
-in a different way. If you don't like what an RM is doing, start
-preparing for your own competing release.</p>
-</section>
-
-<section><title>How does an impending release affect development?</title>
-<p>It can not. Let's repeat that: <b>an impending release can not affect
-development of the project</b>. It is the RM's responsibility to identify
-what changes should make it into the release. The RM may have an
-intermediate tag, so the RM can merge in or reject changes as they are
-committed to the repository's HEAD.</p>
-
-<p>Committers <i>may</i> voluntarily refrain from committing patches if
-they wish to ease the burden on the RM, but they are under
-<font color="red">no</font> obligation to do so. This is one reason why we
-recommend that the RMs have plenty of time on their hands - they may have to
-deal with a rapidly changing target. It's not an easy job.</p>
+<p>The only power held by the RM is the right to determine when the
+current content of subversion is worth their own effort in cutting
+a release candidate. The only thing the RM has authority over is the
+building of a source package, based on the contents of our subversion,
+that can then be put up for vote. They can decide what snapshot revision
+to tag for a candidate. They can decide to branch early and build candidates
+based on the branch rather than a more active development tree, but they
+cannot prevent others from working on that branch as well.
+They can also decide not to build anything at all. They can
+do all sorts of organizational support, advocacy, pleading, or
+whatever in order to encourage the rest of the project committers to
+apply changes, test the candidate, vote for things under issue, etc.</p>
+
+<p>The RM is not a dictator (benevolent or not). They do not have the
+right to pick apart or select any variation of the product they might like
+to release: it has to be a specific tag or revision (moment in time) that
+is present in our subversion and applicable to the version number
+targeted for the release. If there is something they don't like in
+the tree, then they have the same right as other PMC members to change
+or veto that code first, make the change to subversion, and then build
+the release candidate. Likewise, the RM cannot include in the candidate
+any change that has been vetoed by others, and their candidate cannot
+be released if it contains any changes that have been vetoed
+since it was built. The RM has the right to kill their own candidate
+if they learn something during the release process that they think,
+for whatever reason, causes the build to be unreleasable. But the
+RM can't stop anyone else on the PMC from taking the same candidate
+and calling for its release under their own management as RM.</p>
</section>
<section><title>How can an RM be confident in a release?</title>
@@ -102,15 +121,15 @@ it official, and certainly avoid new reg
passed, and now fail).</p>
<p>Another good idea is to coordinate running a candidate on apache.org for
-a period of time. This will require coordination with the current
-maintainers of apache.org's httpd instance. In the past, the group has
-liked to see approximately 48-72 hours of usage in production to certify
-that the release is functional in the real world. Note that some committers
-may choose to not vote on a release until feedback has been gathered from the
-apache.org instance running the release. This is not a requirement (each
-committer is free to come up with their own personal voting guidelines),
-but it produces a feeling of confidence in the release that it will not
-be a <i>dud</i>.</p>
+a period of time. This will require coordination with the infrastructure
+team.
+In the past, the group has liked to see approximately 48-72 hours of
+usage in production to certify that the release is functional in the real
+world. Note that some committers may choose to not vote on a release until
+feedback has been gathered from the apache.org instance running the release.
+This is not a requirement (each committer is free to come up with their own
+personal voting guidelines), but it produces a feeling of confidence in the
+release that it will not be a <i>dud</i>.</p>
</section>
<section><title>How to do a release?</title>
@@ -176,19 +195,18 @@ to overload an earlier tarball with addi
</section>
<section><title>Who can vote?</title>
-<p>For the ASF to release the prepared tarball/archive, at least three
+<p>For the ASF to release the candidate 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
+out to the RM if it was mistakenly included. 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>
+votes cast by PMC members count towards the designation.</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