X Strike Force XFree86 SVN commit: r1357 - /
Author: branden
Date: 2004-05-03 15:29:45 -0500 (Mon, 03 May 2004)
New Revision: 1357
Modified:
NEWS.xhtml
Log:
Update section on the XFree86 bug list.
Modified: NEWS.xhtml
===================================================================
--- NEWS.xhtml 2004-05-03 20:02:53 UTC (rev 1356)
+++ NEWS.xhtml 2004-05-03 20:29:45 UTC (rev 1357)
@@ -923,9 +923,9 @@
<h2 id="bugs">The XFree86 Debian Bug List</h2>
- <p>You too can help with the large bug list. For purposes of this discussion, I am going to assume you're familiar
- with the documentation on how to use the Debian <a href="http://bugs.debian.org/";>Bug Tracking System</a> and
- manipulate bug reports.</p>
+ <p>You too can help with the <a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=xfree86";>large bug list</a>.
+ For purposes of this discussion, I am going to assume you're familiar with the documentation on how to use the
+ Debian <a href="http://bugs.debian.org/";>Bug Tracking System</a> and manipulate bug reports.</p>
<p><em>What you can do:</em></p>
@@ -934,29 +934,52 @@
<p>Reproduce, or decisively refute, existing bug reports. Some of the bug reports are very old, and may have
been fixed upstream. If you can reproduce a bug, no special action is needed unless the original bug report
contained incorrect or incomplete information --- in that case, simply mail the bug with your supplementary
- information. If you can refute a bug report, you should mail the bug and possibly the submitter as well (bug
+ information. If you can refute a bug report, you should mail the bug and possibly the submitter as well (bug
submitters do not automatically receive mails to the bugs they submit, except for the ones to the
- <em>bugnumber</em><tt>-done</tt> address), so that they can see if the problem still exists for them or
- not.</p>
+ <em>bugnumber</em><code>-done</code> address), so that they can see if the problem still exists for them or
+ not. If you do mail a bug submitter requesting more information, be sure to set the <code>moreinfo</code> tag.
+ If you have tried to reproduce a bug, and the bug logs do not show that anyone apart from the submitter has been
+ able to reproduce it either, tag the bug <code>unreproducible</code>.</p>
</li>
<li>
- <p>Identify a bug as being due to upstream code. It's much easier for me to fix bugs in, for instance, the
- Debian control file or the package maintainer scripts than upstream bugs. If a bug is clearly the result of an
- upstream problem, add the <tt>upstream</tt> tag to the bug.</p>
+ <p>Identify a bug as being due to upstream code, by going through the <a
+ href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=xfree86&exclude=upstream";>list of bugs not already
+ tagged <code>upstream</code></a>. It's generally easier for Debian developers to fix bugs in, for instance, the
+ Debian control file or the package maintainer scripts than upstream bugs. If a bug is clearly the result of an
+ upstream problem, add the <code>upstream</code> tag to the bug. In a few rare cases, a bug exists due to a
+ Debian patch to upstream code, and is not actually present upstream. Such bugs should state this specifically
+ in their logs, and should not be tagged <code>upstream</code>.</p>
</li>
<li>
<p>Identify bug reports with patches in them. You do not have to determine whether the patch works or not; I'll
- determine that. Just add the <tt>patch</tt> tag to the bug.</p>
+ determine that. Just add the <code>patch</code> tag to the bug.</p>
</li>
<li>
- <p>Identify bugs that have already been fixed. Whether due to upstream fixes or Debian-specific ones, I don't
- care. Just add the <tt>fixed</tt> tag to the bug.</p>
+ <p>Identify bugs that require more information from the submitter, but which haven't received any. You can do
+ this by going through the <a
+ href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=xfree86&include=moreinfo";>list of bugs tagged
+ <code>moreinfo</code></a>. Bugs tagged <code>moreinfo</code> should have a record in the bug logs of a mail to
+ the <em>bugnumber</em>-<code>submitter</code> address. If they have not, and it is clear to you what
+ information is needed, mail the submitter and request the information. If the bug is tagged
+ <code>moreinfo</code>, you do not know what information is needed, and there is no evidence of the submitter
+ having been mailed, mail the bug and request that the package maintainers follow-up with the bug submitter. If
+ the submitter has been mailed, but has not replied, and the request for more information from the submitter is
+ more than 30 days old, mail the bug and suggest that it be closed due to a lack of response from the
+ submitter.</p>
</li>
<li>
+ <p>Identify bugs that have already been fixed. If it an upstream problem that has been fixed upstream but not
+ yet in the latest Debian package release to unstable, tag the bug <code>fixed-upstream</code>, and mail the bug
+ with a description of the fix (making reference to CVS revisions of the relevant files, if possible). If it's a
+ Debian-specific problem, tag the bug <code>fixed</code> and mail it indicating that it was fixed. In the mail
+ you send, identify which package release fixed the bug, if you know.</p>
+ </li>
+
+ <li>
<p>Merge bug reports that should be merged, and unmerge bug reports that should be unmerged (but see
below).</p>
</li>
@@ -965,22 +988,30 @@
<p><em>What you should not do:</em></p>
<ul>
- <li>Actually close a bug. As the Bug Tracking System documentation states, this should only be done by the bug
- submitter or the package maintainer.</li>
+ <li>
+ <p>Actually close a bug. As the Bug Tracking System documentation states, this should only be done by the bug
+ submitter or the package maintainer.</p>
+ </li>
- <li>Merge or unmerge bug reports unless you're very confident this is appropriate. Sometimes similar-looking
- problems have very different causes. The X server, for instance, may fail to start for any number of reasons, so
- it does not make sense to merge all "the X server crashes"-type bugs. If you have doubts, it won't hurt to simply
- mail the bug with your suspicions that the bug should be merged with, or unmerged from, a specific other bug
- report, and your reasons for your belief.</li>
+ <li>
+ <p>Merge or unmerge bug reports unless you're very confident this is appropriate. Sometimes similar-looking
+ problems have very different causes. The X server, for instance, may fail to start for any number of reasons, so
+ it does not make sense to merge all "the X server crashes"-type bugs. If you have doubts, it won't hurt to
+ simply mail the bug with your suspicions that the bug should be merged with, or unmerged from, a specific other
+ bug report, and your reasons for your belief.</p>
+ </li>
- <li>Change the severity of a bug. There are a few exceptions to this rule, but in general, people seeking to help
- me with the X bug list shouldn't mess with the bug severities. There are probably quite a few wishlist items
- whose severity is currently normal, however, so it would not hurt to mail the bug with your argument for why it
- should be downgraded to a wishlist item.</li>
+ <li>
+ <p>Change the severity of a bug. There are a few exceptions to this rule, but in general, people seeking to help
+ with the X bug list shouldn't mess with the bug severities. There are probably quite a few wishlist items whose
+ severity is currently normal, however, so it would not hurt to mail the bug with your argument for why it should
+ be downgraded to a wishlist item.</p>
+ </li>
- <li>Reassign a bug to a different package. This especially holds true for reassignment to a package I don't
- maintain. Just mail the bug with your reasoning.</li>
+ <li>
+ <p>Reassign a bug to a non-<code>xfree86</code> package. Instead, mail the bug and explain why you think it
+ should be reassigned.</p>
+ </li>
</ul>
<hr />
<!--
Reply to: