You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by ju...@apache.org on 2019/09/03 10:46:12 UTC
svn commit: r1866312 - in /subversion/site/publish: ./
docs/community-guide/releasing.part.html index.html news.html roadmap.html
Author: julianfoad
Date: Tue Sep 3 10:46:11 2019
New Revision: 1866312
URL: http://svn.apache.org/viewvc?rev=1866312&view=rev
Log:
In 'Stabilizing and maintaining releases': merge clarifications from 'staging'.
Modified:
subversion/site/publish/ (props changed)
subversion/site/publish/docs/community-guide/releasing.part.html
subversion/site/publish/index.html (props changed)
subversion/site/publish/news.html (props changed)
subversion/site/publish/roadmap.html (props changed)
Propchange: subversion/site/publish/
------------------------------------------------------------------------------
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Sep 3 10:46:11 2019
@@ -1 +1 @@
-/subversion/site/staging:1812683-1863985
+/subversion/site/staging:1812683-1866311
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=1866312&r1=1866311&r2=1866312&view=diff
==============================================================================
--- subversion/site/publish/docs/community-guide/releasing.part.html (original)
+++ subversion/site/publish/docs/community-guide/releasing.part.html Tue Sep 3 10:46:11 2019
@@ -450,6 +450,12 @@ because its new name is fine.</p>
title="Link to this section">¶</a>
</h3>
+<div class="h4" id="release-stabilization-overview">
+<h4>Overview
+ <a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE" -->#release-stabilization-overview"
+ title="Link to this section">¶</a>
+</h4>
+
<p>Minor and major number releases go through a stabilization period
before release, and remain in maintenance (bugfix) mode after release.
To start the release process, we <a href="#release-branches"
@@ -465,6 +471,10 @@ example, if a set of language bindings i
prudent to make a new release candidate when they are fixed so that
those language bindings may be tested.</p>
+<p>Once the A.B.x branch has been created, no source code changes are
+ever committed to it directly; changes are backported from trunk to the A.B.x
+branch after being voted on, by the process described in the next sections.</p>
+
<p>At the beginning of the final week of the stabilization period, a
new release candidate tarball should be made if there are any
showstopper changes
@@ -503,15 +513,19 @@ style="width: 200px"></a></p>
</ul>
-<p>If there are disagreements over whether a change is potentially
-destabilizing or over whether a bug is critical, they may be settled
-with a committer vote.</p>
-
<p>After the A.B.0 release is out, patch releases (A.B.1, A.B.2, etc.)
follow when bugfixes warrant them. Patch releases do not require a
four week soak, because only conservative changes go into the
line.</p>
+</div> <!-- release-stabilization-overview -->
+
+<div class="h4" id="release-stabilization-backportable-changes">
+<h4>What changes are eligible for backport
+ <a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE" -->#release-stabilization-backportable-changes"
+ title="Link to this section">¶</a>
+</h4>
+
<p>Certain kinds of commits can go into A.B.0 without restarting the
soak period, or into a later release without affecting the testing
schedule or release date:</p>
@@ -554,7 +568,13 @@ time if GNU gettext is in use.</p>
<p>Core code changes, of course, require voting, and restart the soak
or test period, since otherwise the change could be undertested.</p>
-<p>The voting system works like this:</p>
+</div> <!-- release-stabilization-backportable-changes -->
+
+<div class="h4" id="release-stabilization-voting">
+<h4>Voting overview and the electorate
+ <a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE" -->#release-stabilization-voting"
+ title="Link to this section">¶</a>
+</h4>
<p>A change to the A.B.x line must be first proposed in the
<tt>A.B.x/STATUS</tt> file. Each proposal consists of a short identifying
@@ -562,8 +582,8 @@ block (e.g., the revision number of a tr
perhaps an issue number), a brief description of the change, an
at-most-one-line justification of why it should be in A.B.x, perhaps
some notes/concerns, and finally the votes. The notes and concerns
-are meant to be brief summaries to help a reader get oriented; please
-don't use the <tt>STATUS</tt> file for actual discussion, use dev@ instead.</p>
+are meant to be brief summaries to help a reader get oriented.
+Don't use the <tt>STATUS</tt> file for actual discussion; use dev@ instead.</p>
<p>Here's an example, probably as complex as an entry would ever
get:</p>
@@ -588,11 +608,10 @@ get:</p>
-1: jerenkrantz
</pre>
-<p>A change needs three +1 votes from full committers (or partial
-committers for the involved areas), and no vetoes, to go into
-A.B.x. If partial committers would like to vote for a different area,
-which does not fall within their privilege, it must be made clear in
-the <tt>STATUS</tt> file that their vote is 'non-binding' as follows:</p>
+<p>Anyone may vote, but only full committers and partial committers for the
+involved areas have binding votes. When committers cast a non-binding vote
+(such as a partial committer voting for a change outside his nominated area),
+they should annotate their vote as <em>non-binding</em>, like this:
<pre>
* r31833
@@ -603,24 +622,43 @@ the <tt>STATUS</tt> file that their vote
+1 (non-binding): stylesen
</pre>
+<p>This distinction is made in all kinds of votingâbackport voting, release
+voting, and the mythical <a href="https://producingoss.com/en/consensus-democracy.html"
+>votes caused by failure to reach consensus</a>âbut for different reasons.
+In release votes, this distinction is legally required for the release to enter
+ASF's legal shield, whereas in backport votes, it's closer to being an advisory
+distinction. After all, if someone votes -1 on a change for a sound reason,
+their accreditations don't matter; if their analysis is correct, the change
+won't be backported. Likewise, if a change fails to receive <a
+href="#release-stabilization-how-many-votes">the required number</a> of binding
++1 votes but has some non-binding +1 votes, that may help it be approved.</p>
+
+<p>In other words, the purpose of the backport process is to ensure
+destabilizing changes won't enter patch releases. Voting serves that purpose
+by forcing each change to undergo a certain amount of review. Since karma is
+not transferable, we measure "amount of review" in terms of binding votesâbut
+as ever, anyone can give input to the process and be listened to.</p>
+
+</div> <!-- release-stabilization-voting -->
+
+<div class="h4" id="release-stabilization-types-of-votes">
+<h4>Types of votes
+ <a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE" -->#release-stabilization-types-of-votes"
+ title="Link to this section">¶</a>
+</h4>
+
+<p>The voter's opinion of a change is encoded as +1, -1, +0, or -0.</p>
+
+<p class='todo'>Define "veto" or refer to a definition</p>
+
<p>If you cast a veto (i.e. -1), please state the reason in the
concerns field, and include a url / message-id for the list discussion
if any. You can go back and add the link later if the thread isn't
available at the time you commit the veto.</p>
-<p>If you add revisions to a group, note that the previous voters have
-not voted for those revisions, as follows:</p>
-
-<pre>
- * r30643, r30653, r30785
- Update bash completion script.
- Votes:
- +1: arfrever (r30785 only), stylesen
-</pre>
-
-<p>If in case votes have been communicated via IRC or other means,
-note that in the log message. <a href="<!--#echo var="GUIDE_ROLES_PAGE" -->#obvious-fix">Obvious fixes</a>
-do not require '(rX only)' to be mentioned.</p>
+<p>A -0 vote means you somewhat object to a changeâstate your reasons in on
+dev@, or summarize them in a parentheticalâbut won't stand in the way of
+consensus.</p>
<p>Voting +1 on a change doesn't just mean you approve of it in
principle. It means you have thoroughly reviewed the change, and find
@@ -628,7 +666,8 @@ it correct and as nondisruptive as possi
the release branch, the log message will include the names of all who
voted for it, as well as the original author and the person making the
commit. All of these people are considered equally answerable for
-bugs.</p>
+bugs. Committers are trusted to know what they don't know and not
+cast +1 votes lightly.</p>
<p>If you've reviewed a patch, and like it but have some reservations,
you can write "+1 (concept)" and then ask questions on the list about
@@ -638,43 +677,39 @@ toward the total, but they can be useful
are following the change and might be willing to spend more time on
it.</p>
-<p>When votes are listed in the <tt>STATUS</tt> file, they are placed into a
-section for a given release. Some developers may want to vote the
-change into a <b>later</b> release, if (for example) they believe it
-requires further review or testing. Simply add a comment along with
-your vote:</p>
+</div> <!-- release-stabilization-types-of-votes -->
-<pre>
- * r12345
- Fiddle with the hoobey-gidget to clean the garblesnarf.
- Justification:
- All hell breaks loose if the jobbywonk gets out.
- Votes:
- +1: brane
- +1: gstein (for 1.7.2)
-</pre>
+<div class="h4" id="release-stabilization-how-many-votes">
+<h4>How many votes are required
+ <a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE" -->#release-stabilization-how-many-votes"
+ title="Link to this section">¶</a>
+</h4>
+
+<p>A change is approved if it receives three +1s and no vetoes. (Only
+binding votes count; see above.)</p>
-<p>Since votes are tied to specific releases (specified by the section
-they fall under), be very careful when moving change candidates among
-the sections. Existing votes were for the <b>original</b> version, not
-where the candidate has been moved it. Annotate existing votes as
-being cast only for the original version.</p>
-
-<p>There is a somewhat looser voting system for areas that are not
-core code, and that may have fewer experts available to review changes
-(for example, tools/, packages/, bindings/, test scripts, etc.). A
-change in these areas can go in with a +1 from a full committer or a
+<p>Notwithstanding the above, a change that affects only areas that are not
+core code (for example, tools/, packages/, bindings/, test scripts, etc.),
+and that does <em>not</em> affect the build system,
+can go in with a +1 from a full committer or a
partial committer for that area, at least one +0 or "concept +1" from
-any other committer, and no vetoes. (If a change affects the build
-system, however, it is considered a core change, and needs three
-+1's.) Use your judgment and don't review changes unless you have
-some competence to do so, of course. The goal is to get at least two
+any other committer, and no vetoes.</p>
+
+<p>The goal is to get at least two
pairs of eyes on the change, without demanding that every reviewer
have the same amount of expertise as the area maintainer. This way
one can review for general sanity, accurate comments, obvious
mistakes, etc, without being forced to assert "Yes, I understand these
changes in every detail and have tested them."</p>
+</div> <!-- release-stabilization-how-many-votes -->
+
+<div class="h4" id="release-stabilization-how-to-nominate">
+<h4>How to nominate changes into STATUS
+ <a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE" -->#release-stabilization-how-to-nominate"
+ title="Link to this section">¶</a>
+</h4>
+
<p>Before proposing a change in <tt>STATUS</tt>, you should try merging it onto
the branch to ensure that it doesn't produce merge conflicts. If
conflicts occur, please create a new temporary branch from the release
@@ -682,15 +717,58 @@ branch with your changes merged and the
branch should be named <tt>A.B.x-rYYYY</tt>, where YYYY is the first revision
of your change in the <tt>STATUS</tt> file. Add a note in the
<tt>STATUS</tt> file
-about the existence of the temporary branch. If the change involves
+about the existence of the temporary branch in the form of a <tt>Branch:
+A.B.x-rYYYY</tt> or <tt>Branch: ^/subversion/branches/A.B.x-rYYYY</tt> header (use this
+exact form; scripts parse it). If the change involves
further work, you can merge those revisions to the branch. When the
entry for this change is removed from <tt>STATUS</tt>, this temporary branch
should also be removed to avoid cluttering the /branches
directory.</p>
+<p>A temporary branch is also used in the rare case that a change should
+be made to the A.B.x branch that isn't a backport of a change from trunk.</p>
+
+<p>If you nominate an entry that causes merge conflicts until another
+nomination is merged, note that in the nomination. Put a "Depends:" header
+in the entry; that will keep the hourly "detect nominations with merge
+conflict" buildbot job green. (The value of the "Depends:" header is not
+parsed.)</p>
+
+<p>The tools/dist/nominate.pl script (in trunk) automates the process of adding
+a new nomination. The same script also has a REPL loop that helps with the
+process of reviewing nominations and casting votes; see
+tools/dist/README.backport (in trunk).</p>
+
<p>NOTE: Changes to <tt>STATUS</tt> regarding the temporary branch, including
voting, are always kept on the main release branch.</p>
+</div> <!-- release-stabilization-how-to-nominate -->
+
+<div class="h4" id="release-stabilization-how-to-edit">
+<h4>Editing STATUS and annotating votes
+ <a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE" -->#release-stabilization-how-to-edit"
+ title="Link to this section">¶</a>
+</h4>
+
+<p>When adding revisions to a nominations that others have already voted on,
+annotated their entries with "(rX only)" to clarify what parts they have and
+haven't voted on, like this:</p>
+
+<pre>
+ * r30643, r30653, r30785
+ Update bash completion script.
+ Votes:
+ +1: arfrever (r30785 only), stylesen
+</pre>
+
+<p><a href="<!--#echo var="GUIDE_ROLES_PAGE" -->#obvious-fix">Obvious fixes</a>
+do not require '(rX only)' to be mentioned.</p>
+
+<p>If you commit someone else's vote that was communicated via IRC or other
+means, note that in your log message.</p>
+
+</div> <!-- release-stabilization-how-to-edit -->
+
</div> <!-- release-stabilization -->
</div> <!-- release-process -->
Propchange: subversion/site/publish/index.html
------------------------------------------------------------------------------
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Sep 3 10:46:11 2019
@@ -1 +1 @@
-/subversion/site/staging/index.html:1812681-1863985
+/subversion/site/staging/index.html:1812681-1866311
Propchange: subversion/site/publish/news.html
------------------------------------------------------------------------------
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Sep 3 10:46:11 2019
@@ -1 +1 @@
-/subversion/site/staging/news.html:1812681-1863985
+/subversion/site/staging/news.html:1812681-1866311
Propchange: subversion/site/publish/roadmap.html
------------------------------------------------------------------------------
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Sep 3 10:46:11 2019
@@ -1 +1 @@
-/subversion/site/staging/roadmap.html:1812681-1863985
+/subversion/site/staging/roadmap.html:1812681-1866311