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