X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=html%2FReporting.html.in;h=caf81ef9a7d1351d859839d47c5b92ae414407f0;hb=refs%2Fheads%2Fdon%2Fcookies;hp=733fd251b449e1195979e548517f7681d690c393;hpb=14963d032d09f95dcbe10f4e7fadba3338e555ad;p=debbugs.git diff --git a/html/Reporting.html.in b/html/Reporting.html.in index 733fd25..caf81ef 100644 --- a/html/Reporting.html.in +++ b/html/Reporting.html.in @@ -4,44 +4,129 @@ $gReportingHtml = < $gProject $gBugs - how to report a $gBug +

How to report a $gBug in $gProject

+

Important things to note before sending

+ +

Please don't report multiple unrelated $gBugs - especially ones in +different packages - in a single $gBug report. It makes our lives much +easier if you send separate reports. + +

You should check if your $gBug report has already been filed by someone +else before submitting it. Lists of currently outstanding $gBugs are +available on the World Wide Web and +elsewhere - see other documents for details. +You can submit your comments to an existing $gBug report +#<number> by sending e-mail to +<number>\@$gEmailDomain

+ +

If you can't seem to determine which package contains the problem, +please send e-mail to the +$gMaintainerEmail asking for advice. +$gHTMLPseudoDesc +

+ +

If you'd like to send a copy of your $gBug report to additional +recipients (such as mailing lists), you shouldn't use the usual e-mail +headers, but a different method, described below.

+ + +

Sending the bug report using an automatic bug report tool

+ +

There is a program that was developed in Debian to help reporting +$gBug reports, it's called +reportbug. +It will guide you through the bug reporting process step by step, +and probably ease filing bugs that way.

+ +

Emacs users can also use the debian-bug command provided by the + +debbugs-el package. When called with M-x +debian-bug, it will ask for all necessary information in a +similar way to reportbug.

+ + +

Sending the bug report via e-mail

+

Send mail to submit\@$gEmailDomain, -as described below. +as described below.

+ +

Of course, like with any email, you should include a clear, descriptive +Subject line in your main mail header. The subject you +give will be used as the initial $gBug title in the tracking system, so +please try to make it informative!

+ +

You need to put a pseudo-header at the start +of the body of the message. That means that the first line of the message +body should say:

-

Please don't report several unrelated $gBugs - especially ones in -different packages - in one message. Also, please don't mail your $gBug -report to any mailing lists or recipients other than -submit\@$gEmailDomain (for details of how to do this right, see -below). +

+Package: <something>
+
+ +

Replace <something> with the name of the package which +has the $gBug.

+ +

The second line of the message should say:

+ +
+Version: <something>
+
-

Lists of currently-outstanding $gBugs are available on -the World Wide Web and elsewhere - see -other documents for details. +

Replace <something> with the version of the package. +Please don't include any text here other than the version itself, as the +$gBug tracking system relies on this field to work out which releases are +affected by the bug.

-

You need to put a pseudo-header at the start of the body of the -message, with the Package: and Version: -lines giving the name and version of the package which has the $gBug. -(The pseudo-header fields should start at the very start of their lines.) +

You need to supply a correct Package line in the +pseudo-header in order for the $gBug tracking system to deliver the message +to the package's maintainer.

$gHTMLFindPackage -

See below for further requirements. +

The pseudo-header fields should start at the very start of their lines.

$gHTMLPseudoDesc +

Please include in your report:

+ + + +

Include any detail that seems relevant - you are in very little danger +of making your report too long by including too much information. If +they are small please include in your report any files you were using +to reproduce the problem (uuencoding them if they may contain odd +characters etc.).

+ +

Example

A $gBug report, with mail header, looks something like this: + 

   To: submit\@$gEmailDomain
   From: diligent\@testing.linux.org
   Subject: Hello says `goodbye'
-  Package: hello
+
+  Package: hello
   Version: 1.3-16
 
   When I invoke `hello' without arguments from an ordinary shell
@@ -60,33 +145,6 @@ $gHTMLPseudoDesc
   and libc6 2.1.3-10.
-

Please include in your report:

- - - -

Include any detail that seems relevant - you are in very little danger -of making your report too long by including too much information. If -they are small please include in your report any files you were using -to reproduce the problem (uuencoding them if they may contain odd -characters etc.). - -

Of course, like any email, you should include a clear, descriptive -Subject line in your main mail header. The subject you -give will be used as the initial $gBug title in the tracking system, so -please try to make it informative!

Sending copies of $gBug reports to other addresses

@@ -112,6 +170,12 @@ This will cause the $gBug tracking system to send a copy of your report to the address(es) in the X-Debbugs-CC line as well as to any mailing list. +

Avoid sending such copies to the addresses of other $gBug reports, as +they will be caught by the checks that prevent mail loops. There is +relatively little point in using X-Debbugs-CC for this +anyway, as the $gBug number added by that mechanism will just be +replaced by a new one; use an ordinary CC header instead. +

This feature can often be combined usefully with mailing quiet - see below. @@ -123,11 +187,16 @@ request that, you can set the severity level of the $gBug as you report it. This is not required, however, and the developers will assign an appropriate severity level to your report if you do not. -

To assign a severity level put a -Severity: severity line in the pseudo-header, -together with Package and Version. The -severity levels available are described in the -developers' documentation. +

To assign a severity level, put a line like this one in the +pseudo-header:

+ +
+Severity: <severity>
+
+ +

Replace <severity> with one of the available severity +levels, as described in the +developers' documentation.

Assigning tags

@@ -137,11 +206,27 @@ you are including a patch with your $gBug report, you may wish to set the patch tag. This is not required, and the developers will set tags on your report as and when it is appropriate. -

To set tags, put a Tags: tags line in the -pseudo-header together with the usual -Package and Version. The tags available are -described in the +

To set tags, put a line like this one in the +pseudo-header:

+ +
+Tags: <tags>
+
+ +

Replace <tags> with one or more of the available tags, +as described in the developers' documentation. +Separate multiple tags with commas, spaces, or both. + +

+User: <username>
+Usertags: <usertags>
+
+ +

Replace <usertags> with one or more usertags. +Separate multiple tags with commas, spaces, or both. If you specify a +username, that users tags will be set. Otherwise, the email address of +the sender will be used as the username

Not forwarding to the mailing list - minor $gBug reports

@@ -161,6 +246,23 @@ only a summary). any forwarded message so that replies will by default be processed in the same way as the original report. + +

Acknowledgements

+ +

Normally, the $gBug system will return an acknowledgement to you by +e-mail when you report a new bug or submit additional information to an +existing bug. If you want to suppress this acknowledgement, include an +X-Debbugs-No-Ack header in your e-mail (the contents of this +header do not matter; however, it must be in the mail header and +not in the pseudo-header with the Package field). If +you report a new $gBug with this header, you will need to check the web +interface yourself to find the $gBug number.

+ +

Note that this header will not suppress acknowledgements from the +control\@$gEmailDomain mailserver, since those acknowledgements +may contain error messages which should be read and acted upon.

+ +

$gBug reports against unknown packages

If the $gBug tracking system doesn't know who the maintainer of the