Cure for "BAD BUG REPORTS"

[Steef Boerrigter <sxmboer sci kun nl>]

Pavel,


You have more than once cried out for help about people giving useless
bug reports:

> You forgot to mention the MC version and the OS name.  Just imagine
> somebody reporting a problem in _your_ software without telling you the
> version and the OS it's running on!
> 
> To list subscribers: what should we do about such messages?  It's getting
> increasingly annoying, and I'm sorry for adding the messages with "my
> frequently asked questions" to the list traffic.  Moving those question to
> the private discussion is not a good idea - interesting facts in the end
> of the discussion don't appear on the list.  On the other hand, it's
> better to educate people than to ignore them.  Is there any good FAQ
> describing how to report software problems?


I have found a reasonable FAQ on the internet about bug reports:
http://www.rescomp.berkeley.edu/about/HOWTO/Bug-Reports-HOWTO



I would however urge you, Pavel, to include a file in the root directory
of the upcoming mc-4.5.55. I saw a very good example in the source
distribution of XFree86-4.1.0., which I have included for reference
(bug-report).

I've also made another version: bug-report-mc with some changes that are
needed to use it in mc. It is not finished, so you should have a look at
it and add the items that you find are important for mc bugs.


A third alternative is to revert to solely use bugzilla, but I'm not
very keen on that idea myself.

regards,
Steef




-- 
------------------------------------------------------------------------
Drs. S.X.M. Boerrigter
RIM Laboratory of Solid State Chemistry, University of Nijmegen
Toernooiveld 1, 6525 ED  Nijmegen, The Netherlands
Telephone: (+31)-(0)24-3652831    Fax:(+31)-(0)24-3653067
email: sxmboer sci kun nl         http://savannah.gnu.org/users/sxmboer
------------------------------------------------------------------------
Quidquid latine dictum sit, altum viditur.
"Unix was not designed to stop people from doing stupid things,
 because that would also stop them from doing clever things." --Doug
Gwyn
Murphy's law: Anyt<Warning: Mail system error: Unexpected End Of File>

[PLEASE make your Subject: line as descriptive as possible.
Subjects like "xterm bug" or "bug report" are not helpful!]
[Remove all the explanatory text in brackets before mailing.]
[Send to xbugs x org, as shown in the sample message 
header below]

To: xbugs x org
Subject: [area]: [synopsis]   [replace with actual area and short description]

     VERSION:

R6.5.1, public-patch-1

     CLIENT MACHINE and OPERATING SYSTEM:

[e.g. Sparc/SunOS 5.6, S.u.S.E. Linux 5.0 kernel 2.0.30, etc.]

     DISPLAY TYPE:

[e.g. Xsun, Xhp, Xdec, XF86_*, /usr/openwin/bin/Xsun, etc. ]

     WINDOW MANAGER:

[e.g. twm, mwm, fvwm95, enlightenment, etc.]

     COMPILER:

[e.g. native ANSI cc, native cc, ecgs 1.0, etc.]

     AREA:

[Area of the source tree affected,
e.g., Xserver, Xlib, Xt, Xaw, PEX, twm, xterm, xmh, config, ....
Please only one area per bug report.]

     SYNOPSIS:

[Brief description of the problem and where it is located]

     DESCRIPTION:

[Detailed description of problem.  Don't presume that the bug
is self evident. If possible cite specification references (X,
ANSI/POSIX/ISO, X/Open, etc.) to support why it is a bug. For
program crashes a little bit of analysis about why a NULL pointer
was dereferenced or why a buffer overflowed goes a long way.
If this is a request for an enhancement, justify it.]

     REPEAT BY:

[What you did to get the error; include test program or session
transcript if at all possible. Be specific -- if we can't reproduce 
it, we can't fix it.  Don't just say "run this program and it will 
be obvious," tell us exactly what we should see when the program 
is run. Bug reports without a clear, deterministic way of reproducing 
them will be fixed only after all bug reports that do.]

     SAMPLE FIX:

[Please send context diffs (`diff -c original-file fixed-file`).  
Be sure to include the "XConsortium" or "TOG" ident line in any 
diffs -- the best way to do this is to add your own versioning 
line immediately after ours.]

[PLEASE make your Subject: line as descriptive as possible.
Subjects like "xterm bug" or "bug report" are not helpful!]
[Remove all the explanatory text in brackets before mailing.]
[Send to mc-devel gnome org, as shown in the sample message 
header below]

To: mc-devel gnome org
Subject: [area]: [synopsis]   [replace with actual area and short description]

     VERSION:

[e.g. mc-4.5.55]

     CLIENT MACHINE and OPERATING SYSTEM:

[e.g. Sparc/SunOS 5.6, S.u.S.E. Linux 5.0 kernel 2.0.30, etc.]

     WINDOW MANAGER:

[e.g. twm, mwm, fvwm95, enlightenment, etc. only needed for gnome related
issues]

     TERMINAL:

[e.g. rxvt, xterm, linux console, only needed for text based interface]

     COMPILER:

[e.g. native ANSI cc, native cc, ecgs 1.0, gcc 3.0, etc.]

     AREA:

[Area of the source tree affected,
e.g., documentation, editor, vfs, shell...
Please only one area per bug report.]

     SYNOPSIS:

[Brief description of the problem and where it is located]

     DESCRIPTION:

[Detailed description of problem.  Don't presume that the bug
is self evident. If possible cite specification references (X,
ANSI/POSIX/ISO, X/Open, etc.) to support why it is a bug. For
program crashes a little bit of analysis about why a NULL pointer
was dereferenced or why a buffer overflowed goes a long way.
If this is a request for an enhancement, justify it.]

     REPEAT BY:

[What you did to get the error; include test program or session
transcript if at all possible. Be specific -- if we can't reproduce 
it, we can't fix it.  Don't just say "run this program and it will 
be obvious," tell us exactly what we should see when the program 
is run. Bug reports without a clear, deterministic way of reproducing 
them will be fixed only after all bug reports that do.]

     SAMPLE FIX:

[Please send unified diffs (`diff -u original-file fixed-file`).]