Hi,
the attached patch updates the issues.html page to reflect the migration
to JIRA by:
- updating the issue tracker states
- updating the link to get the currently open issues
- replace names of issue tracker fields which differ from the bugzilla ones
in addition the patch also updates the milestones/versions so they look
a bit more up-to-date (1.9.x-example -> 1.10.x).
Regards,
Stefan
Index: issues.part.html
===================================================================
--- issues.part.html (revision 1706325)
+++ issues.part.html (working copy)
@@ -228,19 +228,18 @@
title="Link to this section">¶</a>
</h3>
-<p>For open issues (those whose status is <tt>UNCONFIRMED</tt>,
-<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>
+<p>For open issues (those whose status is <tt>OPEN</tt>,
+<tt>IN PROGRESS</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.10.0 will get a
+<tt>1.10-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
@@ -259,15 +258,15 @@
to when the issue will be addressed.</p>
<p>Continuing the previous example, as development on Subversion
-1.9.0-to-be progresses, developers will be evaluating that feature we
-planned for the release. If we believe that Subversion 1.9 should not
-be released without that feature, we'll change its milestone
-from <tt>1.9-consider</tt> to <tt>1.9.0</tt>; if we hope to release
+1.10.0-to-be progresses, developers will be evaluating that feature we
+planned for the release. If we believe that Subversion 1.10 should
+not be released without that feature, we'll change its milestone
+from <tt>1.10-consider</tt> to <tt>1.10.0</tt>; if we hope to release
with that feature but don't want to commit to it, we'll leave the
-milestone as <tt>1.9-consider</tt>; and if we know good and well we
-aren't going to get around to implementing the feature in the 1.9.x
+milestone as <tt>1.10-consider</tt>; and if we know good and well we
+aren't going to get around to implementing the feature in the 1.10.x
release series, we'll re-milestone the issue to something else
-(<tt>1.10-consider</tt>, perhaps).</p>
+(<tt>1.11-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
@@ -343,13 +342,13 @@
<p>The unmilestoned issues are listed first when you sort by
milestone, and <em>issue triage</em> is the process of trawling
through all the <a
-href="http://subversion.tigris.org/issues/buglist.cgi?component=subversion&issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&order=issues.target_milestone%2C%20issues.priority%2C%20issues.issue_type";
+href="https://issues.apache.org/jira/issues/?jql=project%20%3D%20SVN%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC";
>open issues</a> (starting with the unmilestoned ones), determining
which are important enough to be fixed now, which can wait until
another release, which are duplicates of existing issues, which have
been resolved already, etc. For each issue that will remain open, it
also means making sure that the various fields are set appropriately:
-type, subcomponent, platform, OS, version, keywords (if any), and so
+type, component, environment, version, labels (if any), and so
on.</p>
<p>Here's an overview of the process (in this example, 1.5 is the next
@@ -376,7 +375,7 @@
# Else issue should remain open, so DTRT with it...
- # Set priority, platform, subcomponent, etc, as needed.
+ # Set priority, environment, component, etc, as needed.
adjust_all_fields_that_need_adjustment(i)
# Figure out where to put it.
