871 lines
26 KiB
XML
871 lines
26 KiB
XML
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN"
|
|
"http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd">
|
|
<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
|
|
<!-- :START of Article Metadata -->
|
|
<info><title>Problem Report Handling Guidelines</title>
|
|
|
|
|
|
<legalnotice xml:id="trademarks" role="trademarks">
|
|
&tm-attrib.freebsd;
|
|
&tm-attrib.general;
|
|
</legalnotice>
|
|
|
|
<pubdate>$FreeBSD$</pubdate>
|
|
|
|
<releaseinfo>$FreeBSD$</releaseinfo>
|
|
|
|
<abstract>
|
|
<para>These guidelines describe recommended handling practices
|
|
for FreeBSD Problem Reports (PRs). Whilst developed for the
|
|
FreeBSD PR Database Maintenance Team
|
|
<email>freebsd-bugbusters@FreeBSD.org</email>, these
|
|
guidelines should be followed by anyone working with FreeBSD
|
|
PRs.</para>
|
|
</abstract>
|
|
|
|
<authorgroup>
|
|
<author><personname><firstname>Dag-Erling</firstname><surname>Smørgrav</surname></personname></author>
|
|
|
|
<author><personname><firstname>Hiten</firstname><surname>Pandya</surname></personname></author>
|
|
</authorgroup>
|
|
</info>
|
|
<!-- :END of Article Metadata-->
|
|
|
|
<section xml:id="intro">
|
|
<title>Introduction</title>
|
|
|
|
<para>Bugzilla is an issue management system used by
|
|
the &os; Project. As accurate tracking of outstanding
|
|
software defects is important to FreeBSD's quality, the
|
|
correct use of the software is essential to the forward
|
|
progress of the Project.</para>
|
|
|
|
<para>Access to Bugzilla is available to the entire &os;
|
|
community. In order to maintain consistency within
|
|
the database and provide a consistent user experience, guidelines
|
|
have been established covering common aspects of bug management
|
|
such as presenting followup, handling close requests, and so
|
|
forth.</para>
|
|
</section>
|
|
|
|
<section xml:id="pr-lifecycle">
|
|
<title>Problem Report Life-cycle</title>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>The Reporter submits a bug report on the website. The
|
|
bug is in the <literal>Needs Triage</literal> state.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Jane Random BugBuster confirms that the bug report has
|
|
sufficient information to be reproducible. If not, she goes
|
|
back and forth with the reporter to obtain the needed
|
|
information. At this point the bug is set to the
|
|
<literal>Open</literal> state.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Joe Random Committer takes interest in the PR and
|
|
assigns it to himself, or Jane Random BugBuster decides that
|
|
Joe is best suited to handle it and assigns it to
|
|
him. The bug should be set to the <literal>In
|
|
Discussion</literal> state.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Joe has a brief exchange with the originator (making
|
|
sure it all goes into the audit trail) and determines the
|
|
cause of the problem.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Joe pulls an all-nighter and whips up a patch that he
|
|
thinks fixes the problem, and submits it in a follow-up,
|
|
asking the originator to test it. He then sets the PRs
|
|
state to <literal>Patch Ready</literal>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A couple of iterations later, both Joe and the
|
|
originator are satisfied with the patch, and Joe commits it
|
|
to <literal>-CURRENT</literal> (or directly to
|
|
<literal>-STABLE</literal> if the problem does not exist in
|
|
<literal>-CURRENT</literal>), making sure to reference the
|
|
Problem Report in his commit log (and credit the originator
|
|
if they submitted all or part of the patch) and, if
|
|
appropriate, start an MFC countdown. The bug is set to the
|
|
<literal>Needs MFC</literal> state.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If the patch does not need MFCing, Joe then closes the
|
|
PR as <literal>Issue Resolved</literal>.</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
<note>
|
|
<para>Many PRs are submitted with very little information about
|
|
the problem, and some are either very complex to solve, or
|
|
just scratch the surface of a larger problem; in these cases, it
|
|
is very important to obtain all the necessary information
|
|
needed to solve the problem. If the problem contained within
|
|
cannot be solved, or has occurred again, it is necessary to
|
|
re-open the PR.</para>
|
|
</note>
|
|
</section>
|
|
|
|
<section xml:id="pr-states">
|
|
<title>Problem Report State</title>
|
|
|
|
<para>It is important to update the state of a PR when certain
|
|
actions are taken. The state should accurately reflect the
|
|
current state of work on the PR.</para>
|
|
|
|
<example>
|
|
<title>A small example on when to change PR state</title>
|
|
|
|
<para>When a PR has been worked on and the developer(s)
|
|
responsible feel comfortable about the fix, they will submit a
|
|
followup to the PR and change its state to
|
|
<quote>feedback</quote>. At this point, the originator should
|
|
evaluate the fix in their context and respond indicating
|
|
whether the defect has indeed been remedied.</para>
|
|
</example>
|
|
|
|
<para>A Problem Report may be in one of the following
|
|
states:</para>
|
|
|
|
<glosslist>
|
|
<glossentry>
|
|
<glossterm>open</glossterm>
|
|
<glossdef>
|
|
<para>Initial state; the problem has been pointed out and it
|
|
needs reviewing.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>analyzed</glossterm>
|
|
<glossdef>
|
|
<para>The problem has been reviewed and a
|
|
solution is being sought.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>feedback</glossterm>
|
|
<glossdef>
|
|
<para>Further work requires additional information from the
|
|
originator or the community; possibly information
|
|
regarding the proposed solution.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>patched</glossterm>
|
|
<glossdef>
|
|
<para>A patch has been committed, but something (MFC, or
|
|
maybe confirmation from originator) is still pending.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>suspended</glossterm>
|
|
<glossdef>
|
|
<para>The problem is not being worked on, due to lack of
|
|
information or resources. This is a prime candidate for
|
|
somebody who is looking for a project to take on. If the
|
|
problem cannot be solved at all, it will be closed, rather
|
|
than suspended. The documentation project uses
|
|
<quote>suspended</quote> for <quote>wish-list</quote>
|
|
items that entail a significant amount of work which no one
|
|
currently has time for.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>closed</glossterm>
|
|
<glossdef>
|
|
<para>A problem report is closed when any changes have been
|
|
integrated, documented, and tested, or when fixing the
|
|
problem is abandoned.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
</glosslist>
|
|
|
|
<note>
|
|
<para>The <quote>patched</quote> state is directly related to
|
|
feedback, so you may go directly to <quote>closed</quote> state if
|
|
the originator cannot test the patch, and it works in your own testing.</para>
|
|
</note>
|
|
</section>
|
|
|
|
<section xml:id="pr-types">
|
|
<title>Types of Problem Reports</title>
|
|
|
|
<para>While handling problem reports, either as a developer who has
|
|
direct access to the Problem Reports database or as a contributor who
|
|
browses the database and submits followups with patches, comments,
|
|
suggestions or change requests, you will come across several
|
|
different types of PRs.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><link linkend="pr-unassigned">PRs not yet assigned to anyone.</link></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><link linkend="pr-assigned">PRs already assigned to someone.</link></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><link linkend="pr-dups">Duplicates of existing PRs.</link></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><link linkend="pr-stale">Stale PRs</link></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><link linkend="pr-misfiled-notpr">Non-Bug PRs</link></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>The following sections describe what each different type of
|
|
PRs is used for, when a PR belongs to one of these types, and what
|
|
treatment each different type receives.</para>
|
|
|
|
<section xml:id="pr-unassigned">
|
|
<title>Unassigned PRs</title>
|
|
|
|
<para>When PRs arrive, they are initially assigned to a generic
|
|
(placeholder) assignee. These are always prepended with
|
|
<literal>freebsd-</literal>. The exact value for this default
|
|
depends on the category; in most cases, it corresponds to a
|
|
specific &os; mailing list. Here is the current list, with
|
|
the most common ones listed first:</para>
|
|
|
|
<table xml:id="default-assignees-common">
|
|
<title>Default Assignees — most common</title>
|
|
<tgroup cols="3">
|
|
<thead>
|
|
<row>
|
|
<entry>Type</entry>
|
|
<entry>Categories</entry>
|
|
<entry>Default Assignee</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>base system</entry>
|
|
<entry>bin, conf, gnu, kern, misc</entry>
|
|
<entry>freebsd-bugs</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>architecture-specific</entry>
|
|
<entry>alpha, amd64, arm, i386, ia64, powerpc, sparc64</entry>
|
|
<entry>freebsd-<replaceable>arch</replaceable></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>ports collection</entry>
|
|
<entry>ports</entry>
|
|
<entry>freebsd-ports-bugs</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>documentation shipped with the system</entry>
|
|
<entry>docs</entry>
|
|
<entry>freebsd-doc</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>&os; web pages (not including docs)</entry>
|
|
<entry>Website</entry>
|
|
<entry>freebsd-www</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<table xml:id="default-assignees-other">
|
|
<title>Default Assignees — other</title>
|
|
<tgroup cols="3">
|
|
<thead>
|
|
<row>
|
|
<entry>Type</entry>
|
|
<entry>Categories</entry>
|
|
<entry>Default Assignee</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>advocacy efforts</entry>
|
|
<entry>advocacy</entry>
|
|
<entry>freebsd-advocacy</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>&java.virtual.machine; problems</entry>
|
|
<entry>java</entry>
|
|
<entry>freebsd-java</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>standards compliance</entry>
|
|
<entry>standards</entry>
|
|
<entry>freebsd-standards</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>threading libraries</entry>
|
|
<entry>threads</entry>
|
|
<entry>freebsd-threads</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>&man.usb.4; subsystem</entry>
|
|
<entry>usb</entry>
|
|
<entry>freebsd-usb</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>Do not be surprised to find that the submitter of the
|
|
PR has assigned it to the wrong category. If you fix the
|
|
category, do not forget to fix the assignment as well.
|
|
(In particular, our submitters seem to have a hard time
|
|
understanding that just because their problem manifested
|
|
on an i386 system, that it might be generic to all of &os;,
|
|
and thus be more appropriate for <literal>kern</literal>.
|
|
The converse is also true, of course.)</para>
|
|
|
|
<para>Certain PRs may be reassigned away from these generic
|
|
assignees by anyone. There are several types of assignees:
|
|
specialized mailing lists; mail aliases (used for certain
|
|
limited-interest items); and individuals.</para>
|
|
|
|
<para>For assignees which are mailing lists,
|
|
please use the long form when making the assignment (e.g.,
|
|
<literal>freebsd-foo</literal> instead of <literal>foo</literal>);
|
|
this will avoid duplicate emails sent to the mailing list.</para>
|
|
|
|
<note>
|
|
<para>Since the list of individuals who have volunteered to
|
|
be the default assignee for certain types of PRs changes
|
|
so often, it is much more suitable for <link xlink:href="http://wiki.freebsd.org/AssigningPRs">the FreeBSD wiki</link>.
|
|
</para>
|
|
</note>
|
|
|
|
<para>Here is a sample list of such entities; it is probably
|
|
not complete.</para>
|
|
|
|
<table xml:id="common-assignees-base">
|
|
<title>Common Assignees — base system</title>
|
|
<tgroup cols="4">
|
|
<thead>
|
|
<row>
|
|
<entry>Type</entry>
|
|
<entry>Suggested Category</entry>
|
|
<entry>Suggested Assignee</entry>
|
|
<entry>Assignee Type</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>problem specific to the &arm; architecture</entry>
|
|
<entry>arm</entry>
|
|
<entry>freebsd-arm</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem specific to the &mips; architecture</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-mips</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem specific to the &powerpc; architecture</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-ppc</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem with Advanced Configuration and Power
|
|
Management (&man.acpi.4;)</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-acpi</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem with Asynchronous Transfer Mode (ATM)
|
|
drivers</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-atm</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem with embedded or small-footprint &os;
|
|
systems (e.g., NanoBSD/PicoBSD/FreeBSD-arm)</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-embedded</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem with &firewire; drivers</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-firewire</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem with the filesystem code</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-fs</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem with the &man.geom.4; subsystem</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-geom</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem with the &man.ipfw.4; subsystem</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-ipfw</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem with Integrated Services Digital Network
|
|
(ISDN) drivers</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-isdn</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>&man.jail.8; subsystem</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-jail</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem with &linux; or SVR4 emulation</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-emulation</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem with the networking stack</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-net</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem with the &man.pf.4; subsystem</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-pf</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem with the &man.scsi.4; subsystem</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-scsi</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem with the &man.sound.4; subsystem</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-multimedia</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problems with the &man.wlan.4; subsystem and
|
|
wireless drivers</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-wireless</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem with &man.sysinstall.8; or
|
|
&man.bsdinstall.8;</entry>
|
|
<entry>bin</entry>
|
|
<entry>freebsd-sysinstall</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem with the system startup scripts
|
|
(&man.rc.8;)</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-rc</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem with VIMAGE or VNET functionality and
|
|
related code</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-virtualization</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem with Xen emulation</entry>
|
|
<entry>kern</entry>
|
|
<entry>freebsd-xen</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<table xml:id="common-assignees-ports">
|
|
<title>Common Assignees — Ports Collection</title>
|
|
<tgroup cols="4">
|
|
<thead>
|
|
<row>
|
|
<entry>Type</entry>
|
|
<entry>Suggested Category</entry>
|
|
<entry>Suggested Assignee</entry>
|
|
<entry>Assignee Type</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>problem with the ports framework
|
|
(<emphasis>not</emphasis> with an individual port!)</entry>
|
|
<entry>ports</entry>
|
|
<entry>portmgr</entry>
|
|
<entry>alias</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>port which is maintained by apache@FreeBSD.org</entry>
|
|
<entry>ports</entry>
|
|
<entry>apache</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>port which is maintained by autotools@FreeBSD.org</entry>
|
|
<entry>ports</entry>
|
|
<entry>autotools</entry>
|
|
<entry>alias</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>port which is maintained by doceng@FreeBSD.org</entry>
|
|
<entry>ports</entry>
|
|
<entry>doceng</entry>
|
|
<entry>alias</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>port which is maintained by eclipse@FreeBSD.org</entry>
|
|
<entry>ports</entry>
|
|
<entry>freebsd-eclipse</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>port which is maintained by gecko@FreeBSD.org</entry>
|
|
<entry>ports</entry>
|
|
<entry>gecko</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>port which is maintained by gnome@FreeBSD.org</entry>
|
|
<entry>ports</entry>
|
|
<entry>gnome</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>port which is maintained by hamradio@FreeBSD.org</entry>
|
|
<entry>ports</entry>
|
|
<entry>hamradio</entry>
|
|
<entry>alias</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>port which is maintained by haskell@FreeBSD.org</entry>
|
|
<entry>ports</entry>
|
|
<entry>haskell</entry>
|
|
<entry>alias</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>port which is maintained by java@FreeBSD.org</entry>
|
|
<entry>ports</entry>
|
|
<entry>freebsd-java</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>port which is maintained by kde@FreeBSD.org</entry>
|
|
<entry>ports</entry>
|
|
<entry>kde</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>port which is maintained by mono@FreeBSD.org</entry>
|
|
<entry>ports</entry>
|
|
<entry>mono</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>port which is maintained by
|
|
office@FreeBSD.org</entry>
|
|
<entry>ports</entry>
|
|
<entry>freebsd-office</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>port which is maintained by perl@FreeBSD.org</entry>
|
|
<entry>ports</entry>
|
|
<entry>perl</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>port which is maintained by python@FreeBSD.org</entry>
|
|
<entry>ports</entry>
|
|
<entry>freebsd-python</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>port which is maintained by ruby@FreeBSD.org</entry>
|
|
<entry>ports</entry>
|
|
<entry>freebsd-ruby</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>port which is maintained by secteam@FreeBSD.org</entry>
|
|
<entry>ports</entry>
|
|
<entry>secteam</entry>
|
|
<entry>alias</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>port which is maintained by vbox@FreeBSD.org</entry>
|
|
<entry>ports</entry>
|
|
<entry>vbox</entry>
|
|
<entry>alias</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>port which is maintained by x11@FreeBSD.org</entry>
|
|
<entry>ports</entry>
|
|
<entry>freebsd-x11</entry>
|
|
<entry>mailing list</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>Ports PRs which have a maintainer who is a ports committer
|
|
may be reassigned by anyone (but note that not every &os;
|
|
committer is necessarily a ports committer, so you cannot
|
|
simply go by the email address alone.)
|
|
</para>
|
|
|
|
<para>For other PRs, please do not reassign them to individuals
|
|
(other than yourself) unless you are certain that the assignee
|
|
really wants to track the PR. This will help to avoid the
|
|
case where no one looks at fixing a particular problem
|
|
because everyone assumes that the assignee is already working
|
|
on it.</para>
|
|
|
|
<table xml:id="common-assignees-other">
|
|
<title>Common Assignees — Other</title>
|
|
<tgroup cols="4">
|
|
<thead>
|
|
<row>
|
|
<entry>Type</entry>
|
|
<entry>Suggested Category</entry>
|
|
<entry>Suggested Assignee</entry>
|
|
<entry>Assignee Type</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>problem with PR database</entry>
|
|
<entry>bin</entry>
|
|
<entry>bugmeister</entry>
|
|
<entry>alias</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>problem with Bugzilla <link xlink:href="https://bugs.freebsd.org/submit/">web form</link>.</entry>
|
|
<entry>doc</entry>
|
|
<entry>bugmeister</entry>
|
|
<entry>alias</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
</section>
|
|
|
|
<section xml:id="pr-assigned">
|
|
<title>Assigned PRs</title>
|
|
|
|
<para>If a PR has the <literal>responsible</literal> field set
|
|
to the username of a FreeBSD developer, it means that the PR
|
|
has been handed over to that particular person for further
|
|
work.</para>
|
|
|
|
<para>Assigned PRs should not be touched by anyone but the
|
|
assignee or bugmeister. If you have comments, submit a followup. If for
|
|
some reason you think the PR should change state or be
|
|
reassigned, send a message to the assignee. If the assignee
|
|
does not respond within two weeks, unassign the PR and do as
|
|
you please.</para>
|
|
</section>
|
|
|
|
<section xml:id="pr-dups">
|
|
<title>Duplicate PRs</title>
|
|
|
|
<para>If you find more than one PR that describe the same issue,
|
|
choose the one that contains the largest amount of useful
|
|
information and close the others, stating clearly the number
|
|
of the superseding PR. If several PRs contain non-overlapping
|
|
useful information, submit all the missing information to one
|
|
in a followup, including references to the others; then close
|
|
the other PRs (which are now completely superseded).</para>
|
|
</section>
|
|
|
|
<section xml:id="pr-stale">
|
|
<title>Stale PRs</title>
|
|
|
|
<para>A PR is considered stale if it has not been modified in more
|
|
than six months. Apply the following procedure to deal with
|
|
stale PRs:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>If the PR contains sufficient detail, try to reproduce
|
|
the problem in <literal>-CURRENT</literal> and
|
|
<literal>-STABLE</literal>. If you succeed, submit a
|
|
followup detailing your findings and try to find someone
|
|
to assign it to. Set the state to <quote>analyzed</quote>
|
|
if appropriate.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If the PR describes an issue which you know is the
|
|
result of a usage error (incorrect configuration or
|
|
otherwise), submit a followup explaining what the
|
|
originator did wrong, then close the PR with the reason
|
|
<quote>User error</quote> or <quote>Configuration
|
|
error</quote>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If the PR describes an error which you know has been
|
|
corrected in both <literal>-CURRENT</literal> and
|
|
<literal>-STABLE</literal>, close it with a message
|
|
stating when it was fixed in each branch.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If the PR describes an error which you know has been
|
|
corrected in <literal>-CURRENT</literal>, but not in
|
|
<literal>-STABLE</literal>, try to find out when the person
|
|
who corrected it is planning to MFC it, or try to find
|
|
someone else (maybe yourself?) to do it. Set the state to
|
|
<quote>patched</quote> and assign it to whomever will do
|
|
the MFC.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>In other cases, ask the originator to confirm if
|
|
the problem still exists in newer versions. If the
|
|
originator does not reply within a month, close the PR
|
|
with the notation <quote>Feedback timeout</quote>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
|
|
<section xml:id="pr-misfiled-notpr">
|
|
<title>Non-Bug PRs</title>
|
|
|
|
<para>Developers that come across PRs that look like they should have
|
|
been posted to &a.bugs.name; or some other list should close the
|
|
PR, informing the submitter in a comment why this
|
|
is not really a PR and where the message should be posted.</para>
|
|
|
|
<para>The email addresses that Bugzilla listens to for incoming PRs
|
|
have been published as part of the FreeBSD documentation, have
|
|
been announced and listed on the web-site. This means that
|
|
spammers found them.</para>
|
|
|
|
<para>Whenever you close one of these PRs, please do the
|
|
following:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Set the component to <literal>junk</literal> (under
|
|
<literal>Supporting Services</literal>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Set Responsible to <literal>nobody@FreeBSD.org</literal>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Set State to <literal>Issue Resolved</literal>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Setting the category to <literal>junk</literal> makes it
|
|
obvious that there is no useful content within the PR, and
|
|
helps to reduce the clutter within the main categories.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section xml:id="references">
|
|
<title>Further Reading</title>
|
|
|
|
<para>This is a list of resources relevant to the proper writing
|
|
and processing of problem reports. It is by no means complete.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><link xlink:href="&url.articles.problem-reports;/article.html">How to
|
|
Write FreeBSD Problem Reports</link>—guidelines
|
|
for PR originators.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
</article>
|