Bert Huijben wrote: > Julian Foad wrote: >> The attached patch updates the 'issue-tracker.html' page on Tigris. >> >> However, my commit attempt fails although I have a login and password, >> presumably because the project is locked. Mark, can we temporarily >> unlock it and (you or I) commit this? >> >> Patch log message: >> [[[ >> Update references to the issue tracker on our web site to point to JIRA on >> ASF, following the recent migration from Issuezilla on Tigris. >> >> * www/issue-tracker.html >> Update to point to the new JIRA issue tracker. Add the new priority >> keywords against the old priority numbers. Remove obsolete >> information about requesting 'Observer' role, filing 'Patch' issues, >> and putting Effort estimates in the Status Whiteboard. >> ]]] > > Why do we want to update all this on the old site? > > I don't think we really want to maintain javascripts there that points to the > new Jira... > > My suggestion would be that we should just forward users to the new > issuetracker and for the time being allow access to the historical data. > > Scripts to make access to the current issues easier belong on > subversion.apache.org, or on the Jira instance itself... not on > subversion.tigris.org.
Your suggestion sounds good to me. A new patch is attached, which just redirects to the subversion.a.o/reporting-issues.html. - Julian
Update the issue tracker page on the old Tigris web site to redirect to the equivalent page on our new ASF web site, following the recent migration of the issue tracker. * www/issue-tracker.html Redirect to the corresponding ASF page. --This line, and those below, will be ignored-- Index: www/issue-tracker.html =================================================================== --- www/issue-tracker.html (revision 132) +++ www/issue-tracker.html (working copy) @@ -1,235 +1,14 @@ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> <html xmlns="http://www.w3.org/1999/xhtml";> <head> <title>Subversion Issue Tracker</title> +<meta http-equiv="Refresh" content="0; url='http://subversion.apache.org/reporting-issues.html'"> </head> <body> -<div class="app"> - -<div class="h2"> -<h2>Subversion Issue Tracker</h2> - -<!-- jump to issue form: --> -<form method="get" style="display: inline;" - action="http://subversion.tigris.org/issues/show_bug.cgi"; > -<div style="display: inline;"> -<input name="id" size="6" /> -<input type="submit" value="Jump to issue" /> -</div> -</form> - -<div class="h3" id="guidelines" title="guidelines"> -<h3>Issue Tracker Guidelines</h3> - -<div style="font-size: 115%; background-color: #ff5; - padding: 1em; margin: 0 2em; border: 1px solid black;" - id="buddy-system" title="buddy-system"> - -<!-- "line-height: normal" is required to cancel out the line-height - specification in the sitewide stylesheet for "#bodycol" --> -<p style="font-size: 130%; color: red; text-align: center; - line-height: normal; font-weight: bold;"> -We use the "Buddy System" for filing issues.<br /> -Before filing a new issue, please: -</p> - -<ul> - - <li><p><strong>Re-read the documentation</strong> - (especially the <a href="faq.html">FAQ</a> and the - online <a href="http://svnbook.red-bean.com/"; - >Subversion book</a>).</p></li> - - <!-- Both the link and the search box below will generate results - that include resolved/closed issues. The issue a user is - searching for may have been resolved in a subsequent release or - on trunk, but we still want them to find that issue, so they - don't file a dup. --> - - <li> - <div id="find" title="find"> - <p><strong>Search the issue tracker:</strong></p> - <ul> - <li><p><a - href="http://subversion.tigris.org/issues/buglist.cgi?resort=1&component=subversion;issue_status=UNCONFIRMED;issue_status=NEW;issue_status=STARTED;issue_status=REOPENED;issue_status=RESOLVED;issue_status=VERIFIED;issue_status=CLOSED;email1=;emailtype1=substring;emailassigned_to1=1;email2=;emailtype2=substring;emailreporter2=1;issueidtype=include;issue_id=;changedin=;votes=;chfieldfrom=;chfieldto=Now;chfieldvalue=;short_desc=;short_desc_type=substring;long_desc=;long_desc_type=substring;issue_file_loc=;issue_file_loc_type=substring;status_whiteboard=;status_whiteboard_type=substring;keywords=;keywords_type=anytokens;field0-0-0=noop;type0-0-0=noop;value0-0-0=;newqueryname=;Submit%20query=Submit%20query&order=issues.issue_status%2C%20issues.issue_id"; - >List all existing issues</a></p></li> - <li><form method="get" - action="http://subversion.tigris.org/issues/buglist.cgi";> - <div> - <p> - <input type="submit" value="Search issue summaries:" /> - <input type="hidden" name="component" value="subversion" /> - <input type="hidden" name="short_desc_type" value="substring" /> - <input type="hidden" name="cmdtype" value="doit" /> - <input name="short_desc" /> - </p> - </div></form></li> - <li><p><a href="http://subversion.tigris.org/issues/query.cgi"; - >Structured query of issues database</a></p></li> - </ul> - </div> <!-- find --> - </li> - - <li><p><strong>Find someone else who agrees this is a bug.</strong> - Post to the <a href="mailto:[email protected]" - >[email protected]</a> mailing list (or to - <a href="mailto:[email protected]" - >[email protected]</a> if you're already pretty sure - it's a bug, - <a href="http://subversion.apache.org/docs/community-guide/mailing-lists.html#where-to-post"; - > if in doubt post to the users list</a>), or chat in - <a href="irc://irc.freenode.net/#svn" - >IRC</a>, regarding the bug or feature request you were about to - file. People there will ask you questions, try to reproduce the - problem, advise you if there's any past history of similar - problems, and in general help you decide whether a new issue is - warranted. If it is, they can also help you get the bug report - into a useful form. See - <a href="http://subversion.apache.org/docs/community-guide/issues.html#reporting-bugs"; - >here</a> for how to write a useful bug report.</p> - - <p>If you do file an issue, <em>remember to include a link to - the mailing list message(s) or IRC conversation where you - discussed the problem</em>. Not only does this provide - important context for anyone reading the issue, it also confirms - that the issue has passed the basic buddy test: you found - someone else who agrees it's a problem. Issues that haven't - been through the "buddy system" may be summarily closed. We're - sorry to do this, but statistically, most unbuddied filings turn - out to be bogus, and the issue tracker is not a convenient place - to separate the good reports from the bad.</p></li> - -</ul> - -<p>We depend on the mailing list and IRC channel as a first level of -filtering for our bug tracker. Without this filtering, the tracker -would be full of duplicate issues, non-issues, and unreproducible -issues. Please help us keep the bug database clean, by always finding -a buddy before you file!</p> - -<p>When mailing the list with a concern, make sure that your e-mail -describes your bug or enhancement fully. Provide details about the -versions of the relevant software (Subversion, Apache, neon, etc.) -that you are using, about your operating system, and about any other -thing that might seem pertinent to the issue. If you can provide a -script which consistently reproduces a problem, that can be incredibly -helpful to those evaluating and/or working on your issue.</p> - -</div> <!-- #buddy-system --> - - -</div> - -<div class="h3" id="write-access" title="write-access"> -<h3>Filing New Issues, Modifying Existing Issues</h3> - -<p>You must be <a href="http://subversion.tigris.org/servlets/Login"; ->logged in to the web site</a> to add a new issue, or to comment on -existing issues. To modify existing issues beyond simply leaving a -comment — e.g., to change fields or -status — you must be both logged in and have the -<em>Observer</em> role in the Subversion project; this is true even -for issues that you created yourself.</p> - -<p>Here's how to acquire the <em>Observer</em> role:</p> - -<ol> - <li><a href="http://subversion.tigris.org/servlets/Login"; - >Log in</a> on the tigris.org site</li> - <li>Go to the Subversion project front page</li> - <li>Click on the <em>Request project role</em> link directly below the - "Project Home" line</li> - <li>Request the <em>Observer</em> role</li> - <li>Wait for the confirmation e-mail (almost always will be - completed within 24 hours)</li> -</ol> - -</div> - -<div class="h3" id="fields" title="fields"> -<h3>What the Issue Fields Mean</h3> - -<p>When an issue is first filed, it automatically goes in the -<b>"---"</b> target milestone, which indicates that the issue has not -yet been processed. A developer will examine it and maybe talk to -other developers, then estimate the bug's severity, the effort -required to fix it, and schedule it in a numbered milestone, for -example <b>1.1</b>. (Or they may put it the <b><a -href="http://subversion.tigris.org/issues/buglist.cgi?target_milestone=unscheduled"; ->unscheduled</a></b> or <b><a -href="http://subversion.tigris.org/issues/buglist.cgi?target_milestone=nonblocking"; ->nonblocking</a></b> milestone, if they consider it tolerable for all -currently planned releases.) </p> - -<p>An issue filed in <b>unscheduled</b> might still get fixed soon, -if some committer decides they want it done. Putting it in -<b>unscheduled</b> merely means it hasn't been scheduled for any -particular release yet. The <b>nonblocking</b> milestone, on the -other hand, means that we do not anticipate ever scheduling the issue -for a particular release. This also does not mean the issue will -never be fixed; it merely means that we don't plan to block any -release on it.</p> - -<p>Severity is represented in the <b>Priority</b> field. Here is how -priority numbers map to severity:</p> - -<ul> - - <li><b>P1:</b> <i>Prevents work from getting done, causes data - loss, or BFI ("Bad First Impression").</i> - </li> - - <li><b>P2:</b> <i>Workaround required to get stuff done.</i> - </li> - - <li><b>P3:</b> <i>Like P2, but rarely encountered in normal usage.</i> - </li> - - <li><b>P4:</b> <i>Developer concern only, API stability or - cleanliness issue.</i> - </li> - - <li><b>P5:</b> <i>Nice to fix, but in a pinch we could live with it.</i> - </li> - -</ul> - -<p>Note that we <strong>do not use the PATCH issue type</strong>. -Please select one of the other relevant issue types (DEFECT, -ENHANCEMENT, or FEATURE). If you happen to have a patch to attach to -an issue, or wish to point folks to a patch for the issue that's been -submitted to the mailing list, then add the "patch" keyword to the -issue. Then, attach the patch or reference the mailing list archive -URL of the patch-bearing message as needed.</p> - -<p>Effort Required is represented in the <b>Status Whiteboard</b> with -an "<b>e number</b>", which is the average of the most optimistic and -most pessimistic projections for number of engineer/days needed to fix -the bug. The e number always comes first, so we can sort on the -field, but we include the actual spread after it, so we know when -we're dealing with a wide range. For example -"<b>e2.5 (2 / 3)</b>" is not quite the same as -"<b>e2.5 (1 / 4)</b>"!</p> - -</div> - -</div> - -<div class="h2" id="enter" title="enter"> -<h2>Enter the Issue Tracker</h2> - -<p>And so, with further ado, we give you (drumroll…) the - Subversion <a - href="http://subversion.tigris.org/servlets/ProjectIssues";>Issue - Tracker</a>.</p> - -<p><i>Again, remember that to add or modify issues, you must be <a -href="#write-access">logged into the website</a>.</i></p> - -</div> - -</div> +<p>Redirecting to <a + href="http://subversion.apache.org/reporting-issues.html"; + >http://subversion.apache.org/reporting-issues.html</a></p> </body> </html>
