You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by cm...@apache.org on 2011/07/11 22:51:17 UTC
svn commit: r1145344 -
/subversion/site/publish/docs/community-guide/issues.part.html
Author: cmpilato
Date: Mon Jul 11 20:51:17 2011
New Revision: 1145344
URL: http://svn.apache.org/viewvc?rev=1145344&view=rev
Log:
* site/publish/docs/community-guide/issues.part.html
Line re-wrapping only.
Modified:
subversion/site/publish/docs/community-guide/issues.part.html
Modified: subversion/site/publish/docs/community-guide/issues.part.html
URL: http://svn.apache.org/viewvc/subversion/site/publish/docs/community-guide/issues.part.html?rev=1145344&r1=1145343&r2=1145344&view=diff
==============================================================================
--- subversion/site/publish/docs/community-guide/issues.part.html (original)
+++ subversion/site/publish/docs/community-guide/issues.part.html Mon Jul 11 20:51:17 2011
@@ -224,14 +224,15 @@ understand those distinctions.</p>
<tt>NEW</tt>, <tt>STARTED</tt> or <tt>REOPENED</tt>), the milestone
indicates the Subversion release for which the developers are
targeting the resolution of that issue. In the general case, we use
-milestones of the form <tt><em>MINORVERSION</em>-consider</tt> to indicate
-that the resolution of an issue is being considered as something we'd
-like to release in <em>MINORVERSION</em>.0. For example, a feature we think
-we can and should add to Subversion 1.9.0 will get
-a <tt>1.9-consider</tt> milestone. For obvious reasons, the accuracy
-of these release targets gets increasingly worse the farther into the
-future you look and, as such, users are encouraged to <em>not</em>
-treat them as binding promises from the developer community.</p>
+milestones of the form <tt><em>MINORVERSION</em>-consider</tt> to
+indicate that the resolution of an issue is being considered as
+something we'd like to release in <em>MINORVERSION</em>.0. For
+example, a feature we think we can and should add to Subversion 1.9.0
+will get a <tt>1.9-consider</tt> milestone. For obvious reasons, the
+accuracy of these release targets gets increasingly worse the farther
+into the future you look and, as such, users are encouraged
+to <em>not</em> treat them as binding promises from the developer
+community.</p>
<p>At any given time, there is work toward "the next big release"
happening in the community. As that release begins to take shape, the
@@ -243,8 +244,8 @@ results of those decisions. An issue th
blocker will be moved from the <tt><em>MINORVERSION</em>-consider</tt>
milestone to the <tt><em>MINORVERSION</em>.0</tt> milestone;
"nice-to-haves" will be left with
-the <tt><em>MINORVERSION</em>-consider</tt> milestone; and issues deferred
-from the release will be re-milestoned either
+the <tt><em>MINORVERSION</em>-consider</tt> milestone; and issues
+deferred from the release will be re-milestoned either
with <tt><em>ANOTHERMINORVERSION</em>-consider</tt>
or <tt>unscheduled</tt>, depending on whether we have a clear guess as
to when the issue will be addressed.</p>
@@ -260,8 +261,8 @@ aren't going to get around to implementi
release series, we'll re-milestone the issue to something else
(<tt>1.10-consider</tt>, perhaps).</p>
-<p>The accuracy of the <tt><em>MINORVERSION</em>.0</tt> milestone is very
-important, as developers tend to use those issues to focus their
+<p>The accuracy of the <tt><em>MINORVERSION</em>.0</tt> milestone is
+very important, as developers tend to use those issues to focus their
efforts in the final days of a major release cycle.</p>
</div> <!-- milestones-open -->
@@ -311,8 +312,8 @@ that previous release's version number.
that gets <tt>REOPENED</tt> needs to have its milestone reevaluated in
terms of whether the issue is a release blocker
(<tt><em>MINORVERSION</em>.0</tt>) or not
-(<tt><em>MINORVERSION</em>-consider</tt>). In such situations, it can be
-helpful to consult the issue's change history to see what milestone
+(<tt><em>MINORVERSION</em>-consider</tt>). In such situations, it can
+be helpful to consult the issue's change history to see what milestone
was used before the issue was resolved as fixed.</p>
</div> <!-- milestones-transitioning -->