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 -->