issue-tracker.html [plain text]
<!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>
<style type="text/css"> /* <![CDATA[ */
@import "branding/css/tigris.css";
@import "branding/css/inst.css";
/* ]]> */</style>
<link rel="stylesheet" type="text/css" media="print"
href="branding/css/print.css"/>
<script type="text/javascript" src="branding/scripts/tigris.js"></script>
<title>Subversion Issue Tracker</title>
</head>
<body>
<div class="app">
<div class="h2">
<h2>Subversion Issue Tracker</h2>
<!-- jump to issue form: -->
<table border="0" cellspacing="0" cellpadding="3">
<tr>
<td id="issueid">
<form method="get" action="http://subversion.tigris.org/issues/show_bug.cgi">
<div>
<input name="id" size="6" />
<input type="submit" value="Jump to issue" />
</div>
</form>
</td>
</tr>
</table>
<div class="h3" id="guidelines" title="guidelines">
<h3>Issue Tracker Guidelines</h3>
<div style="color: black; font-size: 130%; font-weight: bold; background-color: #ff5" 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: 200%; color: red; text-align: center; line-height: normal">
We use the "Buddy System" for filing issues.<br />
Before filing a new issue, please:
</p>
<ul>
<li><p>Re-read the documentation<br />
<span style="font-size: 75%; font-weight: normal">
(especially the <a href="faq.html">FAQ</a> and the
online <a href="http://svnbook.red-bean.com/"
>Subversion book</a>).</span></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>Search the issue tracker:</p>
<ul>
<li><p style="font-size: 100%; font-weight: normal;"><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 style="font-size: 100%; font-weight: normal;">
<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 style="font-size: 100%; font-weight: normal;"
><a href="http://subversion.tigris.org/issues/query.cgi"
>Structured query of issues database</a></p></li>
</ul>
</div> <!-- find -->
</li>
<li><p>Find someone else who agrees this is a bug.<br />
<span style="font-size: 75%; font-weight: normal">
Post to the <a href="mailto:users@subversion.tigris.org"
>users@subversion.tigris.org</a> mailing list (or to
<a href="mailto:dev@subversion.tigris.org"
>dev@subversion.tigris.org</a> if you're already pretty sure
it's a bug), 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="bugs.html">here</a> for how to
write a useful bug report.</span></p>
<p><span style="font-size: 75%; font-weight: normal">If you do
file an issue, <i>remember to include a link to the mailing list
message(s) or IRC conversation where you discussed the problem</i>.
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.</span></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>
</div>
<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>
<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>
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>
</body>
</html>