[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Proposal how to handle mass bug reports (was: Re: Bug Terrorism?



On Mon, Mar 16, 1998 at 03:38:12PM -0500, Igor Grobman wrote:
> > With the rash of self-appointed mass-posts of similar bugs (the most
> > recent being Michael Bramer's decision that all xpm files should be
> > moved), I think we need policy as to what can be done when someone trys to
> > formulate policy by bug reports.  I'm more than half inclined to close the
> > slew of reports made without first consulting with debian-policy about
> > them.  I'm sure that it needs to be discussed.

I think the following would be a start:

===============================================================================
Proposal: automated generation of bug reports.

1)   The bug server takes care of reminding maintainers that have packages
   with old unattended bugs. Everyone knows that there are old bugs open.
   There is no need to send reminders without additional information specific
   to the bug. Therefore, sending reminders to a bunch of old bugs just
   because they are old is forbidden.
     Instead, take a look at the old bugs and verify if they still exist.
2)   Lintian can produce warnings and errors automatically. Every developer
   can check his own packages with Lintian, and can fix bugs even before
   uploading the package. The maintainers of Lintian are publishing the list
   of Lintian detecting bugs on a web page and are submitting bug reports for
   critical bugs after a discussion on the public list.
     For this reason, submitting Lintian detected bugs is mostly unnecessary
   and depreciated.
3)   Any bug that can be detected by a script or other automated way should be
   implemented as Lintian check, because then the check applies also to all
   future versions of the package and all advantages of Lintian come into
   play.
     For this reason, it is better to get the check into Lintian than to
   submit the bugs personally; personal auto-generated bug reports are
   therefore unecessary and depreciated.
4)   If you can gather information about a bug with a script, but editing the
   result by hand is necessary, the bug reports are not considered as
   automatically generated. If a lot of packages are affected, submitting of
   the bug should be discussed on the debian development list first.
   Detailed information about the bug and the number of affected packages
   should be included.
5)   A bug is by definition a bug in the software or a violation of policy.
   However, the policy generally allowes exceptions.
   Most of the time, automated bug reports cover violations of policy.
   It is your responsibility to be sure that the bugs you submit really
   *are* a violation of policy *before* you send the bugs. If policy is not
   clear, the bugs should not be sent, but a discussion on the debian policy
   list should be started.
===============================================================================


This is probably a bit rough, but it is probably a start. We have lintian
for automated bug reports now, so why should we allowe another way?

This is easily annoying and a waste of bandwidth and time, as some reactions
of developers have shown.

Thank you for considering,
Marcus


-- 
"Rhubarb is no Egyptian god."        Debian GNU/Linux        finger brinkmd@ 
Marcus Brinkmann                   http://www.debian.org    master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09


--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: