www/project_issues.html - subversion - Git at Google

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

   <li><p>Look through <a
       href="http://subversion.tigris.org/issues/buglist.cgi?component=subversion&amp;issue_status=UNCONFIRMED&amp;issue_status=NEW&amp;issue_status=STARTED&amp;issue_status=REOPENED"
       >all existing issues</a>, or search their summaries:</p>
       <form method="get"
         action="http://subversion.tigris.org/issues/buglist.cgi"><div>
       <input name="short_desc" />
       <input type="submit" value="Search!" />
       <input type="hidden" name="component" value="subversion" />
       <input type="hidden" name="issue_status" value="NEW" />
       <input type="hidden" name="issue_status" value="STARTED" />
       <input type="hidden" name="issue_status" value="REOPENED" />
       <input type="hidden" name="short_desc_type" value="substring" />
       <input type="hidden" name="cmdtype" value="doit" />
       </div></form>
       <p style="font-size: 75%; font-weight: normal">
       to see if this bug has already been reported.</p></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 logged in to the web site to add a new issue, or
 comment on existing issues.  To modify aspects of issues other than
 simply leaving a comment (i.e., to change fields or status), you must
 be logged in, and possess the <em>Observer</em> role in the Subversion
 project&nbsp;&mdash;&nbsp;even for issues that you created
 yourself.</p>

 <p>Here's how to acquire the <em>Observer</em> role:</p>

 <ol>
   <li>Log in 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
     &quot;Project Home&quot; 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&nbsp;(2&nbsp;/&nbsp;3)</b>" is not quite the same as
 "<b>e2.5&nbsp;(1&nbsp;/&nbsp;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&hellip;) 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>
	<!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>

	<li><p>Look through <a
	href="http://subversion.tigris.org/issues/buglist.cgi?component=subversion&issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED"
	>all existing issues</a>, or search their summaries:</p>
	<form method="get"
	action="http://subversion.tigris.org/issues/buglist.cgi"><div>
	<input name="short_desc" />
	<input type="submit" value="Search!" />
	<input type="hidden" name="component" value="subversion" />
	<input type="hidden" name="issue_status" value="NEW" />
	<input type="hidden" name="issue_status" value="STARTED" />
	<input type="hidden" name="issue_status" value="REOPENED" />
	<input type="hidden" name="short_desc_type" value="substring" />
	<input type="hidden" name="cmdtype" value="doit" />
	</div></form>
	<p style="font-size: 75%; font-weight: normal">
	to see if this bug has already been reported.</p></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 logged in to the web site to add a new issue, or
	comment on existing issues. To modify aspects of issues other than
	simply leaving a comment (i.e., to change fields or status), you must
	be logged in, and possess the <em>Observer</em> role in the Subversion
	project — even for issues that you created
	yourself.</p>

	<p>Here's how to acquire the <em>Observer</em> role:</p>

	<ol>
	<li>Log in 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>