FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 03-01-2011, 06:13 PM
"Jesús M. Navarro"
 
Default What bug reports are for

Hi, Russ:

En fecha Martes, 1 de Marzo de 2011, Russ Allbery escribió:
> "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.

No, I don't think it is. #3 *is* a bug since the moment somebody has referred
it as such.

> 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).

That maybe the case, but you won't know till you take the time to research it.
All you know prior to that is that it is there, on the bug tracking system,
therefore it is a bug.

> 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.

Completly agreed, but absolutly unrelated. That it is no worth paying
attention to it (even if that's truly the case) makes it any less of a bug.

> 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.

I think I'll go here into troubled waters but It's my opinion (as somebody
that has worked implementing and policying issue tracking systems, so I think
it's an informed opinion, but just an opinion nevertheless) that there's no
thing such too long a bug list.

What it usually happens (at least in my experience) is that too long a bug
list hurts the ego of the one that think of himself as being responsible for
that so we, being humans the way we are, feel a strong inclination to
"resolve" it by whatever means we find and being an easy scape path sweeping
them under the carpet, that's what we'll do. It takes a strong and well-
ballanced ego just to recognize that, well, there's simply not enough man-
power to deal with it, so focus must be centered on what brings better cost-
benefit ratio (bugs #1 and #2) and let #3 accumulate even if that makes for an
"ugly" bug list for the 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.

Which, again, is a perfectly acceptable outcome with a perfectly acceptable
remediation (me, the user, stepping forward to offer my help). Sweeping bugs
under the carpet is not a valid remediation even as the long bug list is
heartly painful for its maintainer.

Cheers.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201103012013.07026.jesus.navarro@undominio.net">ht tp://lists.debian.org/201103012013.07026.jesus.navarro@undominio.net
 
Old 03-01-2011, 06:15 PM
Don Armstrong
 
Default What bug reports are for

On Tue, 01 Mar 2011, Jess M. Navarro wrote:
> Is *that* Debian's official position? That the bug report system is
> not there to offer a service to Debian users?

The BTS exists to help maintainers fix and track fixed bugs in their
packages. The service to users comes from the BTS enabling maintainers
to fix their bugs.

While it's certainly not optimal, closing bugs which are
unreproducible or incomplete are sometimes necessary because we do not
have an infinite amount of maintainers to fix bugs. If there are
people who feel strongly about helping to get these unreproducible or
incomplete bugs in a state where someone can actually resolve them,
then please, form a crew, and start working on them. Feel free to let
owner@bugs.debian.org know how you want to know about these bugs if
you need some additional features in the BTS. We certainly could use
more bug triagers.

Haranguing maintainers who are doing a best-effort job or further
discussion on -devel about this should not be necessary.


Don Armstrong

--
Your village called.
They want their idiot back.
-- xkcd http://xkcd.com/c23.html

http://www.donarmstrong.com http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110301191519.GQ5061@teltox.donarmstrong.com">htt p://lists.debian.org/20110301191519.GQ5061@teltox.donarmstrong.com
 
Old 03-01-2011, 06:22 PM
Russ Allbery
 
Default What bug reports are for

"Jess M. Navarro" <jesus.navarro@undominio.net> writes:

> I think I'll go here into troubled waters but It's my opinion (as
> somebody that has worked implementing and policying issue tracking
> systems, so I think it's an informed opinion, but just an opinion
> nevertheless) that there's no thing such too long a bug list.

I completely disagree. And that's also an informed opinion.

> What it usually happens (at least in my experience) is that too long a
> bug list hurts the ego of the one that think of himself as being
> responsible for that so we, being humans the way we are, feel a strong
> inclination to "resolve" it by whatever means we find and being an easy
> scape path sweeping them under the carpet, that's what we'll do.

You've basically said here that everyone who disagrees with you on what
methods are practically effective in bug management is just suffering from
a bruised ego. This comes across as condescending rather than as a
foundation for a useful discussion.

I pointed out in my previous message some of the practical problems with
leaving all the type 3 bugs active in the BTS, and in previous threads on
this topic others have pointed similar issues in considerably more depth.
If you want to convince people not to close type 3 bugs on packages where
there's no resources to deal with them, you're going to have to engage
with those arguments and understand the problems that they're trying to
solve by closing those bugs (and recognize that they *are* solving
problems, not just assuaging their egos).

--
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: 87bp1uzlva.fsf@windlord.stanford.edu">http://lists.debian.org/87bp1uzlva.fsf@windlord.stanford.edu
 
Old 03-01-2011, 06:24 PM
"Jess M. Navarro"
 
Default What bug reports are for

Hi, Ian:

En fecha Martes, 1 de Marzo de 2011, Ian Jackson escribi:
> 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.

Please pay attention that those are related to upstream maintainers, not
developers; it is doubtful that it can be of application to packagers, since
packager's self-appointed duty is for the software to be easily accesable and
integrated for the user (were it not the case, the end user could simply take
the tarball directly from the developer).

And with regards of Debian and the thread at hand, maybe there's not an official
position on what the bug tracking system exactly is for but certainly there's
quite an interesting document you may have some notice of: Debian Social
Contract, points 3 and 4.

(/me fastly ducks away after having the balls of telling *that* to Ian Jackson
no less)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201103012024.36619.jesus.navarro@undominio.net">ht tp://lists.debian.org/201103012024.36619.jesus.navarro@undominio.net
 
Old 03-01-2011, 06:33 PM
Neil Williams
 
Default What bug reports are for

On Tue, 1 Mar 2011 19:47:58 +0100
"Jesús M. Navarro" <jesus.navarro@undominio.net> wrote:

> 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?

Service != support.

Debian and Debian systems like the BTS are there to support users and
to support Debian, that's clear in the Social Contract but that does not
mean that Debian provides a contractual service of any kind. Support is
one thing but all such support comes from volunteers and there is no
"customer service", no "service contract", no warranties, no guarantees.
Volunteers do what they can in their own free time. There's no room
there for formal services to users or anyone else.

If you want a service contract, find a GNU/Linux distribution capable
of supplying one, it is not Debian. Debian exists to support users, not
enter a service contract with users.

http://www.debian.org/social_contract

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 
Old 03-01-2011, 06:33 PM
"Jess M. Navarro"
 
Default What bug reports are for

Hi, Don:

En fecha Martes, 1 de Marzo de 2011, Don Armstrong escribi:
> On Tue, 01 Mar 2011, Jess M. Navarro wrote:
> > Is *that* Debian's official position? That the bug report system is
> > not there to offer a service to Debian users?
>
> The BTS exists to help maintainers fix and track fixed bugs in their
> packages. The service to users comes from the BTS enabling maintainers
> to fix their bugs.
>
> While it's certainly not optimal, closing bugs which are
> unreproducible or incomplete are sometimes necessary because we do not
> have an infinite amount of maintainers to fix bugs.

Certainly my fault for not being able to make myself clear enough: of course
it's OK to close unreproducible/incomplete bugs, specially if the bug tracking
system allows to close them as such. But only after due dilligence to really
be able to asses them as such.

I.e.: I don't have any problem with a bug being answered by its maintainer in
a line something like "in order to be able to reproduce this bug I need you to
provide me with foo and bar. Failing that I'll close it in 30 days with Zoot
status" (of course being "foo and bar" something sensible, not just a way to
take it from over my roof).

> If there are
> people who feel strongly about helping to get these unreproducible or
> incomplete bugs in a state where someone can actually resolve them,
> then please, form a crew, and start working on them. Feel free to let
> owner@bugs.debian.org know how you want to know about these bugs if
> you need some additional features in the BTS. We certainly could use
> more bug triagers.

That's a worthy idea. I'll take a time to think about it.

Cheers.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201103012033.59513.jesus.navarro@undominio.net">ht tp://lists.debian.org/201103012033.59513.jesus.navarro@undominio.net
 
Old 03-01-2011, 06:52 PM
"Jess M. Navarro"
 
Default What bug reports are for

Hi, Russ:

En fecha Martes, 1 de Marzo de 2011, Russ Allbery escribi:
> "Jess M. Navarro" <jesus.navarro@undominio.net> writes:
> > I think I'll go here into troubled waters but It's my opinion (as
> > somebody that has worked implementing and policying issue tracking
> > systems, so I think it's an informed opinion, but just an opinion
> > nevertheless) that there's no thing such too long a bug list.
>
> I completely disagree. And that's also an informed opinion.
>
> > What it usually happens (at least in my experience) is that too long a
> > bug list hurts the ego of the one that think of himself as being
> > responsible for that so we, being humans the way we are, feel a strong
> > inclination to "resolve" it by whatever means we find and being an easy
> > scape path sweeping them under the carpet, that's what we'll do.
>
> You've basically said here that everyone who disagrees with you on what
> methods are practically effective in bug management is just suffering from
> a bruised ego. This comes across as condescending rather than as a
> foundation for a useful discussion.

If that's what I said, then take it for deleted.

What I *tried* to say, is that I've been there, I've felt my ego hurted, and
after lenghty conversations with those working under my responsibility more
times than not that was the case too. And after assesing that as the main
problem we were able to find ways for better issue management both for those
filling the issues and those having to deal with them.

> I pointed out in my previous message some of the practical problems with
> leaving all the type 3 bugs active in the BTS

No, you didn't (not at least that I managed to understand as such). What you
did was telling what happened (that #3 bugs tend to cost too much time for too
short a benefit, a thing the bug triager is only able to know after the fact,
or else he could simply let it be untouched) and telling that longer opened
bug lists take more overhead to deal with (which is not something my
experience can relate to -not at least in any significant manner).

> , and in previous threads on
> this topic others have pointed similar issues in considerably more depth.

Well, I'll have to re-read those threads then since that's not what I can
remember of them right now.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201103012052.41404.jesus.navarro@undominio.net">ht tp://lists.debian.org/201103012052.41404.jesus.navarro@undominio.net
 
Old 03-01-2011, 07:42 PM
Russ Allbery
 
Default What bug reports are for

"Jess M. Navarro" <jesus.navarro@undominio.net> writes:

> No, you didn't (not at least that I managed to understand as such).
> What you did was telling what happened (that #3 bugs tend to cost too
> much time for too short a benefit, a thing the bug triager is only able
> to know after the fact, or else he could simply let it be untouched)

That wasn't the part that I was referring to; that's a different part of
the analysis. (However, I believe you're wrong in your contention that a
bug triager can only estimate the work/benefit ratio after studying the
bug in depth.)

> and telling that longer opened bug lists take more overhead to deal with
> (which is not something my experience can relate to -not at least in any
> significant manner).

Your experience doesn't match the experience of many other people who have
posted to these threads. I think you're going to have to show us the
details of what we're doing wrong.

I also mentioned the affect of long bug lists on increased duplicate bug
filings via reportbug, which I've noticed and which can have significant
impact (particularly on the annoyance factor of duplicate bugs).

There was rather extensive discussion earlier with lots more examples in
one of the other threads (we've had lots) about this topic. I thought you
were also participating them, but I could be misremembering.

Some of these may be technical issues with the BTS that could be
resolvable by making it easier to stick bugs into an easily-ignored
bucket, but one of the points that has been raised in the past is that
it's very unclear to many of us that sticking bugs into a bucket that, in
practice, guarantees no one will look at them within the next five years
is actually doing our users any favors over simply closing the bug.

--
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: 87r5aqy3m2.fsf@windlord.stanford.edu">http://lists.debian.org/87r5aqy3m2.fsf@windlord.stanford.edu
 
Old 03-03-2011, 09:42 AM
Andrei Popescu
 
Default What bug reports are for

On Ma, 01 mar 11, 19:33:09, Neil Williams wrote:
>
> If you want a service contract, find a GNU/Linux distribution capable
> of supplying one, it is not Debian. Debian exists to support users, not
> enter a service contract with users.

There's plenty paid support for Debian as well:
http://www.debian.org/consultants

Regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
 

Thread Tools




All times are GMT. The time now is 04:54 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org