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

Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh segfaults as , a result of new libc 2.0.7r2



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
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


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


Reply to: