Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   What bug reports are for (http://www.linux-archive.org/debian-development/494736-what-bug-reports.html)

Josselin Mouette 02-27-2011 01:33 PM

What bug reports are for
 
Le dimanche 27 février 2011 * 14:50 +0200, Dmitry Baryshev a écrit :
> Who should do this investigation? I did it because I know how to debug
> this. If user don't know how to debug this, his bug report will be
> closed without reassigning to proper package. Hence this investigation
> should be done by maintainer, not user.

You seem to forget the very reason bug reports are here. Their point is
not to offer a service to our users - if you want that, you’ll need paid
support. Bug reports are here to help improving the distribution.

Now, maintainers receive a lot of bug reports, and have limited time to
spare on Debian. Given the choice between:
1. packaging a new upstream release that fixes a lot of bugs;
2. fixing a nicely reported bug with a reproducible and
well-identified cause;
3. investigating a dubious bug report that seems to be triggered by
a broken user configuration;
only masochistic maintainers will spend time on #3 when they can help a
lot more users on #1 and #2. It’s not that it’s easier (I remember
spending entire days on single bugs), but it’s more useful.

Now, if you spend enough time investigating to be able to tell, at the
very least, “this is a bug in library foo which is reproducible by doing
bar”, your report might go from #3 to #2 and get fixed.

Cheers,
--
.'`. Josselin Mouette
: :' :
`. `' “If you behave this way because you are blackmailed by someone,
`- […] I will see what I can do for you.” -- Jörg Schilling

Dmitry Baryshev 02-27-2011 02:13 PM

What bug reports are for
 
At http://www.debian.org/Bugs/Reporting is is said that we should not send bugs to program authors, but to only Debian BTS. Imagine some system service reads configuration file, and has critical bug in parsing it. User cannot debug this. Maintainer closes this bug report with explanation "this is a bug in something else in your system" (for example, in an unknown backend library or GUI frontend). Critical bug will be closed and ignored, right?


2011/2/27 Josselin Mouette <joss@debian.org>

Le dimanche 27 février 2011 * 14:50 +0200, Dmitry Baryshev a écrit :

> Who should do this investigation? I did it because I know how to debug

> this. If user don't know how to debug this, his bug report will be

> closed without reassigning to proper package. Hence this investigation

> should be done by maintainer, not user.



You seem to forget the very reason bug reports are here. Their point is

not to offer a service to our users - if you want that, you’ll need paid

support. Bug reports are here to help improving the distribution.



Now, maintainers receive a lot of bug reports, and have limited time to

spare on Debian. Given the choice between:

* * 1. packaging a new upstream release that fixes a lot of bugs;

* * 2. fixing a nicely reported bug with a reproducible and

* * * *well-identified cause;

* * 3. investigating a dubious bug report that seems to be triggered by

* * * *a broken user configuration;

only masochistic maintainers will spend time on #3 when they can help a

lot more users on #1 and #2. It’s not that it’s easier (I remember

spending entire days on single bugs), but it’s more useful.



Now, if you spend enough time investigating to be able to tell, at the

very least, “this is a bug in library foo which is reproducible by doing

bar”, your report might go from #3 to #2 and get fixed.



Cheers,

--

*.'`. * * *Josselin Mouette

: :' :

`. `' *“If you behave this way because you are blackmailed by someone,

*`- * *[…] I will see what I can do for you.” *-- Jörg Schilling





--
Regards, Krasu

"Jesús M. Navarro" 02-28-2011 09:57 PM

What bug reports are for
 
Hi, Josselin:

En fecha Domingo, 27 de Febrero de 2011, Josselin Mouette escribió:
[...]
> Now, maintainers receive a lot of bug reports, and have limited time to
> spare on Debian. Given the choice between:
> 1. packaging a new upstream release that fixes a lot of bugs;
> 2. fixing a nicely reported bug with a reproducible and
> well-identified cause;
> 3. investigating a dubious bug report that seems to be triggered by
> a broken user configuration;
> only masochistic maintainers will spend time on #3 when they can help a
> lot more users on #1 and #2. It’s not that it’s easier (I remember
> spending entire days on single bugs), but it’s more useful.

True, and I don't think anybody would expect any more.

But #3. is still a bug and unless it's been at least tried to be reproduced is
no good behaviour to close it just "because I've not the time and I prefer
focusing on #1 and #2".

I'm not telling this is the case for this bug since I really don't know it but
as a general matter, but *if* that were the case, no, I don't think sweeping
bugs under the carpet is a proper policy.

Cheers.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201102282357.49765.jesus.navarro@undominio.net">ht tp://lists.debian.org/201102282357.49765.jesus.navarro@undominio.net

Vincent Bernat 02-28-2011 10:13 PM

What bug reports are for
 
OoO En ce début d'après-midi ensoleillé du dimanche 27 février 2011,
vers 15:33, Josselin Mouette <joss@debian.org> disait*:

> You seem to forget the very reason bug reports are here. Their point is
> not to offer a service to our users - if you want that, you’ll need paid
> support. Bug reports are here to help improving the distribution.

> Now, maintainers receive a lot of bug reports, and have limited time to
> spare on Debian. Given the choice between:
> 1. packaging a new upstream release that fixes a lot of bugs;
> 2. fixing a nicely reported bug with a reproducible and
> well-identified cause;
> 3. investigating a dubious bug report that seems to be triggered by
> a broken user configuration;
> only masochistic maintainers will spend time on #3 when they can help a
> lot more users on #1 and #2. It’s not that it’s easier (I remember
> spending entire days on single bugs), but it’s more useful.

> Now, if you spend enough time investigating to be able to tell, at the
> very least, “this is a bug in library foo which is reproducible by doing
> bar”, your report might go from #3 to #2 and get fixed.

The last message of Dmitry points to the culprit (use of Tahoma
font). This seems a valid bug. I have added this instruction to my gtkrc
but did not succeed to reproduce the bug (I get the black screen but it
is not expanding). Maybe there is something else to add (using
KDE?). We don't know if Sandro succeeded to reproduce this bug after the
Dmitry provided additional info because he just closed the bug.

In my opinion, Sandro should have left the bug open with its
"unreproducible" tag. The bug is not solved and should not have been
closed. It would have been nice to reevaluate the "unreproducible" tag
with the help of the additional input from the reporter. Some users
don't bother to help the maintainer and we have here a user which is
willing to debug the problem. This seems a bad idea to just close its
bug without interacting with him.
--
BOFH excuse #306:
CPU-angle has to be adjusted because of vibrations coming from the nearby road

Russ Allbery 02-28-2011 10:17 PM

What bug reports are for
 
"Jesús M. Navarro" <jesus.navarro@undominio.net> writes:
> En fecha Domingo, 27 de Febrero de 2011, Josselin Mouette escribió:

>> Now, maintainers receive a lot of bug reports, and have limited time to
>> spare on Debian. Given the choice between:
>> 1. packaging a new upstream release that fixes a lot of bugs;
>> 2. fixing a nicely reported bug with a reproducible and
>> well-identified cause;
>> 3. investigating a dubious bug report that seems to be triggered by
>> a broken user configuration;
>> only masochistic maintainers will spend time on #3 when they can help a
>> lot more users on #1 and #2. It’s not that it’s easier (I remember
>> spending entire days on single bugs), but it’s more useful.

> True, and I don't think anybody would expect any more.

> But #3. is still a bug and unless it's been at least tried to be
> reproduced is no good behaviour to close it just "because I've not the
> time and I prefer focusing on #1 and #2".

> I'm not telling this is the case for this bug since I really don't know
> it but as a general matter, but *if* that were the case, no, I don't
> think sweeping bugs under the carpet is a proper policy.

Well, maybe #3 is still a bug. That's the problem, right? We don't know
that.

The trouble with things that fall into category #3, apart from just taking
way more time to investigate, is that they may or may not actually be
bugs. Frequently once one investigates, one finds that it's not a bug in
any useful fashion (it's already fixed, it's caused by something on the
user side against which it's not reasonable for the package to take
precautions, the user's system was in some broken state, or no one can
reproduce the problem and the user isn't replying). And it can take a lot
of time to get to that point of realizing that something in #3 isn't an
actionable bug.

Meanwhile, #1 and #2 are much more efficient in terms of maintainer time
to fixed bug ratio.

The #3 reports aren't *useless* in aggregate (although individual cases of
#3 often are individually useless), but they are almost always less useful
in improving the package quality than #1 and #2. This means that they're
probably still worth spending time on if all #1 and #2 tasks are complete,
but if there are #1 and #2 tasks pending, #3 is probably not worth paying
attention to.

Now, for most packages, #1 and #2 bugs tend to get resolved relatively
quickly, or at least end up in some stable state (such as understanding a
#2 bug but realizing it's going to take a ton of work to fix), so
maintainers get to the #3 bugs. But what happens with a package that gets
so many bugs that maintainers can't get to all the #1 and #2 bugs? Are #3
bugs actually even useful to track at that point?

I think one of the arguments being made in recent discussions is that if
one is already overwhelmed with bugs of type #1 and #2, even tracking bugs
of type #3 may be more trouble than it's worth. The additional overhead
of having the appear in bug listings and the additional users who file
duplicate bugs because the bug list is so long they fail to check for
duplicates at all may cause more aggregate work than the #3 bugs provide
in utility for that package. And we have a fair number of packages in
Debian that get enough bug reports on an ongoing basis, relative to the
number of people working on them, that the chances of us ever cleaning out
all the #1 and #2 bugs and having it be worth our time to work on #3 bugs
is essentially zero.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87sjv7lpey.fsf@windlord.stanford.edu">http://lists.debian.org/87sjv7lpey.fsf@windlord.stanford.edu

Holger Levsen 03-01-2011 07:56 AM

What bug reports are for
 
Hi,

On Montag, 28. Februar 2011, Jess M. Navarro wrote:
> But #3. is still a bug and unless it's been at least tried to be reproduced
> is no good behaviour to close it just "because I've not the time and I
> prefer focusing on #1 and #2".

I don't think it's the maintainers duty to prove that bugs are bugs, but
rather the submitters.

If maintainers go out of their way to help reproducing bugs, great. But if
they don't want to, thats totally fine too.

And then it's also fine to close unreproducable bugs which one suspects are
due to local, aeh, constraints. Reopening once they are found to be
reproducable is easy :-)


cheers,
Holger

"Bernhard R. Link" 03-01-2011 09:37 AM

What bug reports are for
 
* Holger Levsen <holger@layer-acht.org> [110301 09:56]:
> On Montag, 28. Februar 2011, Jess M. Navarro wrote:
> > But #3. is still a bug and unless it's been at least tried to be reproduced
> > is no good behaviour to close it just "because I've not the time and I
> > prefer focusing on #1 and #2".
>
> I don't think it's the maintainers duty to prove that bugs are bugs, but
> rather the submitters.

It's the maintainers interest and the job they volunteered for to look
after the package and thus also find bugs and fix them in the one or
other way (for example by reporting them upstream in a way upstream can
properly deal with that). The bug reporter is someone simply helping
here.

It makes sense to focus on bugs one can deal with and ask the submitter
for more help with bugs one cannot deal with yourself. It can be
acceptable to close bug reports once there is no hope a bug can be
identified and fixed with it (so the costs of having the report open
(like making bug lists harder to read thus making it harder to report
and fix bugs) are bigger than the expected benefits of having it
(probability this is an actual bug * probability it can be found due to
this report * probability it hits again * costs it causes).

Of course packages with many bugs and little maintainer man-power
usually have heigher costs per bug (more crowded bug lists) and smaller
expected benefits (smaller probability the bug will be found), so it can
for some packages make more sense to close a report than for smaller
packages.

But still a bug report is mostly an try to help us improve the software
we care for. Like every other attempt to help it can be counterproductive,
but we should be careful to not discourage people trying to help us.

> And then it's also fine to close unreproducable bugs which one suspects are
> due to local, aeh, constraints. Reopening once they are found to be
> reproducable is easy :-)

That means someone must be actually looking at it. Closed bugs are not
that often looked at in my experience.


Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110301103752.GA12186@pcpool00.mathematik.uni-freiburg.de">http://lists.debian.org/20110301103752.GA12186@pcpool00.mathematik.uni-freiburg.de

Holger Levsen 03-01-2011 10:13 AM

What bug reports are for
 
Hi Bernhard,

"Debian Bug report logs - #615153
exec: 58: /usr: Permission denied
Package: general; Maintainer for general is debian-devel@lists.debian.org;"

I think you just volunteered ;-)


cheers,
Holger

"Jesús M. Navarro" 03-01-2011 05:47 PM

What bug reports are for
 
Hi, Josselin:

En fecha Domingo, 27 de Febrero de 2011, Josselin Mouette escribió:
> Le dimanche 27 février 2011 * 14:50 +0200, Dmitry Baryshev a écrit :
> > Who should do this investigation? I did it because I know how to debug
> > this. If user don't know how to debug this, his bug report will be
> > closed without reassigning to proper package. Hence this investigation
> > should be done by maintainer, not user.
>
> You seem to forget the very reason bug reports are here. Their point is
> not to offer a service to our users - if you want that, you’ll need paid
> support. Bug reports are here to help improving the distribution.

Good to know.

Is *that* Debian's official position? That the bug report system is not there
to offer a service to Debian users?

Cheers.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201103011947.58328.jesus.navarro@undominio.net">ht tp://lists.debian.org/201103011947.58328.jesus.navarro@undominio.net

Ian Jackson 03-01-2011 05:53 PM

What bug reports are for
 
Jess M. Navarro writes ("Re: What bug reports are for"):
> Hi, Josselin:
> > You seem to forget the very reason bug reports are here. Their point is
> > not to offer a service to our users - if you want that, you?ll need paid
> > support. Bug reports are here to help improving the distribution.
>
> Good to know.
>
> Is *that* Debian's official position? That the bug report system is
> not there to offer a service to Debian users?

Debian doesn't have an "official position" on this question. But I
would guess it is the position of the vast majority of Debian's
maintainers.

This has been standard wisdom for Free Software for decades now. See
for example this extract from the GNU "Information for Maintainers"
document:

The main purpose of bug reports is to help you contribute to the
community by improving the next version of the program. Many of the
people who report bugs don't realize this-they think that the point is
for you to help them individually. Some will ask you to focus on that
instead of on making the program better. If you comply with their
wishes, you will have been distracted from the job of maintaining the
program.

...

When people ask you to put your time into helping them use the
program, it may seem "helpful" to do what they ask. But it is much
less helpful than improving the program, which is the maintainer's
real job.

http://www.gnu.org/prep/maintain/maintain.html#Replying-to-Mail

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 19821.16552.732033.436662@chiark.greenend.org.uk"> http://lists.debian.org/19821.16552.732033.436662@chiark.greenend.org.uk


All times are GMT. The time now is 06:51 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.