Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh segfaults as , a result of new libc 2.0.7r2
Dale Scheetz wrote:
>
> On 29 Jun 1998, Manoj Srivastava wrote:
>
> > Hi,
> > >>"Rob" == Rob Browning <rlb@cs.utexas.edu> writes:
> >
> > Rob> Dale Scheetz <dwarf@polaris.net> writes:
> > >> What I am requesting is that the submitter of a bug take some time, in
> > >> exchange for the time they expect from the maintainer, and verify that the
> > >> bug has not been reported already. If it has, it is appropriate to send
> > >> the maintainer a confirmation that you also experienced the bug and any
> > >> additional information you can contribute to the solution. This
> > >> confirmation should be CC'd to the original bug report, for continuity
> > >> purposes. But creating an additional report is both confusing and
> > >> administrativly ugly.
> >
> > Rob> This should be mandated (I thought it was). Not that I've always been
> > Rob> as careful as I should have been, but I've tried to be pretty good.
> > Rob> It's extremely helpful (especially for high-traffic-area/critical
> > Rob> packages like X and libc) that you not end up with floods of redundant
> > Rob> bugs.
> >
> > Umm, no. It would be nice if they did it, but a novce user is
> > perfectly free to just file a bug report. I know I often do. I find
> > an error, usually that by itself is a frustrating experience, also,
> > it is likely to be in the middle of a largish upgrade (I upgrade ever
> > so often). I am not into going over and looking up stuff in the
> > archive for a dozen pacxkages; I just send a report.
>
> When you do so, without adequate investigation, you imply that the
> understanding and repair of the bug is the sole responsibility of the
> maintianer. I submit, in the free software community, that this is a bogus
> position. Because of the freedom we provide, the user bears some
> responsibility in the maintainance of the products they use. I suggest
> that any bug report that says no more than "xxx is broken" is a useless
> report submitted by a lazy user, and, until more information is
> forthcoming, is not likely to produce results.
>
> >
> > Make bug reporting any more onerous than it is, and peole
> > merely stop filing reports.
> >
> What is so "onerous" about checking to see if the bug has already been
> reported? As Rob said, it could provide the "work around" information that
> is needed to resolve the problem.
>
> Suggesting, even strongly, that it is proper proceedure when submitting a
> bug, to research the bug reporting system first, and provide useful
> information second, doesn't seem onerous to me, and has several practical
> uses for the bug submitter, as well as the maintainer.
>
> > For the most part the maintainer knows the bugs on a package
> > better than anyone else, and the maintainers are fairly well versed
> > in the Bug system; merging bugs is not all that hard.
> >
> Merging bugs is not that hard, but it also doesn't provide any bookkeeping
> advantages to the maintainer. The bugs still get reported in the
> "problems" report separately. Nags still come separately. This requires
> that the maintainer keep records of which bugs have been merged.
>
> > I realize when you inherit a package with a gazillion bugs
> > that is not as easy; but it gets better as you get more familiar with
> > the bugs on your packages.
>
> NO, it doesn't. I spent one hole weekend, just after I took over glibc,
> going over all of the bug reports on that package. I was able to retire 30
> bugs (out of 120) that were either fixed, or no longer a problem. During
> that time period 50 bug reports were submitted against this package. So,
> after a weekends work I had managed to get behind by an additional 20 bug
> reports. :-(
>
> If you look at the list today, you will see many ancient bug reports on
> locales and timezones which pre-date glibc. How does one deal with these?
>
> I am tempted to close all "ancient" bug reports on principle, but that
> certainly violates the spirit, if not the letter of policy.
>
> >
> > Rob> Not only that, but the user might discover a workaround in the bug log
> > Rob> that helps them out. This might be the best way to "sell" the idea :>
> >
> > Yes. It is a good idea. It just should not be mandatory.
>
> Mandatory is a non-functional term in this group. Nothing is mandatory
> (even though some would wish it were) in a voluntary organization.
>
> I am only suggesting that we make clear that the socially correct way to
> report a bug involves adequate research on the part of the bug reporter.
> This "requirement" provides additional service to the user at the same
> time that it provides the maintainer with more chance to fix the problem.
>
> Waiting is,
>
> Dwarf
Here is my two cents worth as a novice user:
First, lets get the above information put in a place where new novice users
can't miss. In other words put it right under their nose. At the end of
the install procedure of future Debs, have the tail end of the install
script (before they are taken to dselect?) point them to a few critical
plain text files *already on the system* (put them in the base system) in a
/usr/doc/dir location. Consider making everyone page thru this info (in the
install script) before 'letting them go'. Make them plain text so you don't
force a tender newbie to have to figure out how to use latex/tex/whatever.
This file(s) should do the following things:
a) Tell them of the existence not only of www.debian.org but this user
mailing list as well. Don't assume every person is going to come to
www.debian.org right off the bat on their own initiative, discover the
mailing lists (and figure out how to sign themselves up), plus discover the
bug reporting system. They may not get a browser set up for awhile, so let
them know *before-hand* what is expected. Otherwise, when they do get their
ppp/mail/browser working, if they ran into a problem, they might blunder
right in to submitting a bug or wasting bandwidth on the mailing list when
they should have done something else. They need to know about this
important source of information (www.debian.org) from the very beginning.
b) Explain how to submit a bug including the concerns mentioned above. A
very, VERY helpful option would be to provide an http-based (via
www.debian.org) automated procedure to fill out a bug report. This
procedure would include a check of previous bug reports, so the user can see
whether his problem has already been reported. I know setting up something
like this is a non-trivial operation - so take my suggestion here as an item
for the "wish-list". Don't simply tell them to use the bug package. The
bug package is not useful to everyone, because it assumes everyone has
installed a standard mail system, which will increasingly not be the case.
A lazy novice user (refugee from DOS/Win world) like me will prefer to just
use NS Communicator (or future equivalent) which does www/mail/news without
the difficulty of install and configuring the arcane
smail/fetchmail/mutt/inews/inewsinn combination (plus God knows what else is
required).
c) Other locations on the net where they can get info and support (when Deb
starts using GNOME, for example, we can point them to gnome.org).
I don't know of polite way to say this, but a little hand-holding at the
very beginning will save you maintainers some grief later on down the road.
The current bug reporting procedure is already complicated; look at how
long http://www.debian.org/Bugs/Reporting.html is already. We need to find
a way to make it simpler, not add more to it.
Feel free to flame away! :-)
--
Ed
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: