RFC: additions to the article "problem-reports"
pepper at reppep.com
Fri May 9 20:37:09 UTC 2003
At 6:51 PM -0500 2003/05/08, Mark Linimon wrote:
>+ <para><emphasis>Be specific</emphasis>
>+ The more information you supply about what problem you
>+ are having, the better your chance of getting a response.
>+ You should include such things as what version you are
>+ running (there is a place to put that, see below);
>+ which architecture you are running on;
>+ whether you are running from a release CDROM, or from
>+ a system maintained by &cvsup.1; (and, if so, how
>+ recently you updated); and, if a kernel problem,
>+ if you have read <literal>src/UPDATING</literal>
>+ (someone is guaranteed to ask). You do not necessarily
>+ have to provide your kernel configuration, which ports
>+ you have available, and a core dump (including these
>+ by default only tends to fill up the database), but you
>+ should be prepared to make them available, either
>+ privately or publicly, if so asked.</para>
I think the Environment: line already shows the kernel
version, which should be -RELEASE or -STABLE or something similar, so
you shouldn't have to say whether it came from CD, although if you
cvsupped long before doing the kernel build, that's unusual enough to
be worth mentioning.
>+ <para><emphasis>Avoid controversial requests</emphasis>
>+ If your PR addresses an area that has been controversial
>+ in the past, you should probably be prepared to not only
>+ offer patches, but also justification for why the patches
>+ are The Right Thing To Do. As noted above, a careful
>+ search of past mailing lists is always good preparation.
s/past mailing lists/the appropriate mailing lists for
The mailing lists themselves are more likely current...
>- <para>The template consists of a list of fields, some of which
>- are pre-filled, and some of which have comments explaining
>+ <para>When you run &man.send-pr.1;, you are presented with a
>+ template. The template consists of a list of fields, some of
>+ which are pre-filled, and some of which have comments explaining
> their purpose or listing acceptable values. Do not worry
> about the comments; they will be removed automatically if you
> do not modify them or remove them yourself.</para>
Something odd happened to the spacing here.
It's probably worth mentioning
<http://www.freebsd.org/send-pr.html>, even if just to say it's no
Separately, if this is a permanent state of affairs (it's
been 4+ months), s/currently disabled/permanently disabled/ for "The
web-based bug interface is currently disabled." on that page.
It's also worth suggesting that people fix their From: &
Reply-To: lines in send-pr -- mine, at least, always default to
<pepper>, which isn't useful. I think send-pr from GNATS 4 will allow
overriding this default, but don't know if anyone's working on
updating the GNATS installation...
Chris Pepper: <http://www.reppep.com/~pepper/>
Rockefeller University: <http://www.rockefeller.edu/>
More information about the freebsd-doc