Re: That need to close bugs?

[Christian Robottom Reis]

On Fri, Sep 28, 2007 at 12:03:00PM +0200, Alexander Sack wrote:
> On Thu, Sep 27, 2007 at 03:07:15PM +1200, Matthew Paul Thomas wrote:
> >
> > And third, some teams use statuses in odd ways. For example, a while ago 
> > the Ubuntu Mozilla team were using "In Progress" when they really meant 
> > "Won't Fix" (I don't know whether they still do this). And as we've seen 
> > from the recent Incomplete fallout, some developers have been using 
> > "Incomplete" for bug reports that aren't actually incomplete.
> 
> I find it interesting that you call other ways to look at bug
> statuses 'odd', while not considering that maybe your intepretation
> sounds odd to me (and probably to others as well).

I have written a Launchpad news entry that clarifies the semantics of
bug statuses:

http://news.launchpad.net/general/of-bugs-and-statuses

I'll be posting this to ubuntu-devel shortly so that a wider audience
can consider this.

> Anyway, I am open to look at bug statuses used by mozillateam again,
> but not before you have landed your _final_ one and only great way to
> triage bugs ;). Currently things are still moving too fast and from

There will always be potential for change, but ground zero is clarifying
what our current statuses are for. There are quite a few cases that we
need to think though carefully: for instance, what status should we use
for distro bugs that are waiting for upstream work; or what should
happen to Incomplete bugs that have information provided. I'll be
posting more news entries that try and move forward on identifying
processes to handle these special cases. Stay tuned to

http://news.launchpad.net/category/bug-tracking

Enjoy!
-- 
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3376 0125

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Matthew Paul Thomas]

On Sep 28, 2007, at 10:03 PM, Alexander Sack wrote:


On Thu, Sep 27, 2007 at 03:07:15PM +1200, Matthew Paul Thomas wrote:


And third, some teams use statuses in odd ways. For example, a while 
ago the Ubuntu Mozilla team were using "In Progress" when they really 
meant "Won't Fix" (I don't know whether they still do this). And as 
we've seen from the recent Incomplete fallout, some developers have 
been using "Incomplete" for bug reports that aren't actually 
incomplete.


I find it interesting that you call other ways to look at bug
statuses 'odd', while not considering that maybe your intepretation
sounds odd to me (and probably to others as well).


Of course, if it was all obvious we wouldn't even be having this 
discussion. :-)


The original motivation was to have a status meaning: "The bug isn't 
our fault, and we're not going to do anything to fix or work around it, 
other than notifying the bug's actual source. (E.g. notifying upstream 
if we're a distribution, or notifying the relevant distribution if 
we're upstream.) But other people will still have the problem and 
search for it, so it should still appear in search results by default." 
As opposed to Invalid, which doesn't appear in search results by 
default.


On further thought, though, that use of "Won't Fix" still suffers from 
the scalability problem I mentioned earlier. Ten years from now, for 
any search you did, a large chunk of the results would likely be 
ancient "Won't Fix" bugs. And if we fixed that by hiding "Won't Fix" in 
search results by default, then it would be functionally identical to 
"Invalid", so there'd be no point in having both statuses after all.



BTW, when the mozilla team setup their workflow, there wasn't a state
"Won't fix" at all ... and _rejecting_ upstream bugs on ubuntu side is
just hard to explain to reporters and definitly triggers noise in the
bug from unhappy reporters. (and btw, I think the same is still valid
for |Won't fix|).


Yes, I agree that's a problem. I wonder if "Declined" would be a more 
pacific name.



Anyway, I am open to look at bug statuses used by mozillateam again,
but not before you have landed your _final_ one and only great way to
triage bugs ;).
...


Fair enough, I'll get back to you in a couple of years. ;-) Meanwhile, 
though, you'll have occasional confusion as people used to reporting 
bugs elsewhere in Launchpad encounter the different meanings you're 
using.


Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/


PGP.sig
Description: This is a digitally signed message part
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Alexander Sack]

On Thu, Sep 27, 2007 at 03:07:15PM +1200, Matthew Paul Thomas wrote:
>
> And third, some teams use statuses in odd ways. For example, a while ago 
> the Ubuntu Mozilla team were using "In Progress" when they really meant 
> "Won't Fix" (I don't know whether they still do this). And as we've seen 
> from the recent Incomplete fallout, some developers have been using 
> "Incomplete" for bug reports that aren't actually incomplete.

I find it interesting that you call other ways to look at bug
statuses 'odd', while not considering that maybe your intepretation
sounds odd to me (and probably to others as well).

BTW, when the mozilla team setup their workflow, there wasn't a state
"Won't fix" at all ... and _rejecting_ upstream bugs on ubuntu side is
just hard to explain to reporters and definitly triggers noise in the
bug from unhappy reporters. (and btw, I think the same is still valid
for |Won't fix|).

Anyway, I am open to look at bug statuses used by mozillateam again,
but not before you have landed your _final_ one and only great way to
triage bugs ;). Currently things are still moving too fast and from
what I remember there are plans to extend the bug statuses another
time ... later adding ACL barriers et al ... so for me it doesn't make
much sense to change the mozillateams interpretation of bug statuses
right now, because I just cannot tell atm if those would be void in 6
month or 2 weeks.

 - Alexander


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Matthew Paul Thomas]

Just to pick up one question that wasn't answered during this thread ...

On Sep 18, 2007, at 2:58 AM, Reinhard Tartler wrote:


"Fergal Daly" <[EMAIL PROTECTED]> writes:
...

What is the rationale behind skipping closed bugs in a search? I've
been burned by this in the past.

I can understand why the QA guys or the even developers would want
this but for a user, who is actually making the effort to not only
report a bug but to search for dups first, why would they want to
ignore closed bugs? Closed bugs often contain exactly what that user
needs - a workaround or a timeline for the fix to be released,


I think this is a very interesting question. Are there any (publicy
viewable) specs which explain the various use cases for querying bugs?
...


Closed bug reports are excluded from bug listings because, in theory, 
they are not relevant to the current version of the software -- so bug 
reporters won't be searching for them anyway, and including them would 
result in ever-increasing noise. In particular, "Invalid" bug reports 
are (in theory) not bugs at all, and "Fix Released" bugs are (again, in 
theory) fixed in a released version of the software such as Ubuntu 
7.04.


In Ubuntu currently, practice is quite different from that theory in a 
few ways. First, bug reports are routinely marked "Fix Released" when 
there has not, in fact, been any Ubuntu release in which the bug is 
fixed. This is Launchpad's fault, partly because mass status changes 
haven't been implemented yet (so it's impractical to mass-change the 
Fix Committed bugs to Fix Released when the Ubuntu version is 
released), but also partly because we didn't communicate the meaning of 
the statuses properly to begin with, and also partly because "released" 
for Ubuntu is a slippery term anyway. (Does a non-LTS version count? or 
a beta? or an alpha?)


Second, we were slow in introducing "Won't Fix Here" (so that in the 
meantime people got used to using "Rejected"/"Invalid" instead), and 
even then we called it "Won't Fix", so again it's not obvious what it 
means. (In brief, use "Won't Fix" when a bug affects this software but 
this software is not an appropriate place to fix it. For example it 
affects Ubuntu 6.10 but will never be fixed for that version, or it 
affects Firefox in Ubuntu but will never be fixed unless Mozilla fixes 
it upstream.)


And third, some teams use statuses in odd ways. For example, a while 
ago the Ubuntu Mozilla team were using "In Progress" when they really 
meant "Won't Fix" (I don't know whether they still do this). And as 
we've seen from the recent Incomplete fallout, some developers have 
been using "Incomplete" for bug reports that aren't actually 
incomplete.


Now, we could just wave away all these problems by making the default 
search return bug reports regardless of status. However, that wouldn't 
scale -- ten years from now, for any search you did, 90% of the results 
would be old closed bug reports from ancient versions. (The same 
applies to the "Is the bug you're reporting one of these?" list, which 
currently includes closed bug reports regardless of age: that can't 
last.) So we should figure out how to solve the problems some other 
way, and the sooner we do, the less painful it will be.


Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/


PGP.sig
Description: This is a digitally signed message part
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Alexander Sack]

On Sat, Sep 22, 2007 at 10:38:29AM +0100, Matthew Garrett wrote:
> On Thu, Sep 20, 2007 at 12:58:25PM +0100, Colin Watson wrote:
> 
> > I agree entirely. What drives *me* batty in turn is when people take a
> > confirmed, complete report, ask why it hasn't been fixed yet, and close
> > it as invalid because obviously something that's been around for a
> > couple of releases can't be relevant any more. Or when people reject
> > perfectly valid and complete wishlist bugs (note that it usually takes a
> > lot less for a wishlist bug to be complete) because they should be
> > specifications (they shouldn't, in most cases) or just because they're
> > wishlist. As a developer, I wish I didn't have to spend time checking my
> > bug mail just to make sure that well-intentioned but mistaken triagers
> > aren't taking items off my to-do list that I want to stay there.
> 
> Something appears to have flagged all inactive bugs as invalid. Apart 
> from generating a ridiculous quantity of email for no obviously good 
> reason, a pile of perfectly valid wishlist bugs or issues that require 
> further work in the rest of the distribution first have suddenly closed. 
> Who on earth thought that this was a good idea?
> 

I can only agree that forcing such a feature on all users of launchpad
is definitly not right. Maybe there are some projects/packages that
want that feature, however almost certainly not all. At least make
this feature opt-out on a package/project base ... or imo even better
opt-in.

 - Alexander


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

LP 1.1.9 considered harmful (was Re: That need to close bugs?)

[Scott Kitterman]

On Saturday 22 September 2007 05:38, Matthew Garrett wrote:
> On Thu, Sep 20, 2007 at 12:58:25PM +0100, Colin Watson wrote:
> > I agree entirely. What drives *me* batty in turn is when people take a
> > confirmed, complete report, ask why it hasn't been fixed yet, and close
> > it as invalid because obviously something that's been around for a
> > couple of releases can't be relevant any more. Or when people reject
> > perfectly valid and complete wishlist bugs (note that it usually takes a
> > lot less for a wishlist bug to be complete) because they should be
> > specifications (they shouldn't, in most cases) or just because they're
> > wishlist. As a developer, I wish I didn't have to spend time checking my
> > bug mail just to make sure that well-intentioned but mistaken triagers
> > aren't taking items off my to-do list that I want to stay there.
>
> Something appears to have flagged all inactive bugs as invalid. Apart
> from generating a ridiculous quantity of email for no obviously good
> reason, a pile of perfectly valid wishlist bugs or issues that require
> further work in the rest of the distribution first have suddenly closed.
> Who on earth thought that this was a good idea?
>
This is apparently by design (at least in part).

The theory (and I don't agree with it) appears to have been that if 
information was asked for from a reporter and it was not gotten for some 
period of time, then an incomplete bug could be marked invalid.

Even if the theory was valid, the current implementation appears to be marking 
all bugs that have been in an incomplete state for 60 days as invalid 
independent of if there has been activity on the bug.  See:

https://bugs.launchpad.net/bugs/141652

for details.

I took about an hour to go through the stack of bugmail I got about this and I 
did not find a single bug that should have been closed (in my opinion) that 
could not have been closed by marking it Fix Released with the bug it's a 
dupe of was marked.  

60 days is to short.  Even if we set a time, there are classes of bugs (such 
as crashes) that even if incomplete are not invalid (a crash bug is always a 
bug).  I don't think bugs should get marked invalid except manually.

In my opinion, there have been a number of feature additions to LP recently 
that were not well thought through.  A few additional examples:

1.  Allowing PPA uploads to auto close bugs. (I know this one is fixed now, 
but it boggles my mind to think how it could have been overlooked)

2  Including a backports release as the current Ubuntu release on the new 
package page (I'm not a fan of the new page, but that aside, the concept is 
not well thought through).

3.  Including changelog fragments on the new package page (easy to find 
incomplete information can be actively dangerous).

I know that the LP developers are working very hard to provide a useful tool.  
This is not meant to be an attack on their efforts or their competence.  The 
real problem (as it appears to me as an outsider) is a lack of process focus 
on good up front design and an excessive faith in "well catch it in the beta" 
to surface flaws.

I promised sabdfl on IRC that I wouldn't exaggerate about problems, so I went 
back through the 1.1.9 release announcement to see if there were any changes 
that had affected me (most don't) that I liked.  I came up with:

* When Launchpad is offline, you will now be able to see if it
   is offline for maintenance or offline unexpectedly.

Finally, I used to be able to add a link to an upstream bug.  I appear to have 
lost that ability for anything that's not "registered" in Launchpad.  I'm not 
about to sit through registering every package I touch to do upstream bug 
linking.

Scott K

P.S.  This is on an Ubuntu list and not an LP list because I think that this 
upgrade is bad for Ubuntu and am concerned about our future productivity if 
the trend continues.  This is an Ubuntu issue.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Caroline Ford]

And all the duplicates have closed - duplicates naturally don't have any
further progress.

I don't think 60 days is long enough either, but that's a different
point.

Caroline
On Sat, 2007-09-22 at 10:38 +0100, Matthew Garrett wrote:
> On Thu, Sep 20, 2007 at 12:58:25PM +0100, Colin Watson wrote:
> 
> > I agree entirely. What drives *me* batty in turn is when people take a
> > confirmed, complete report, ask why it hasn't been fixed yet, and close
> > it as invalid because obviously something that's been around for a
> > couple of releases can't be relevant any more. Or when people reject
> > perfectly valid and complete wishlist bugs (note that it usually takes a
> > lot less for a wishlist bug to be complete) because they should be
> > specifications (they shouldn't, in most cases) or just because they're
> > wishlist. As a developer, I wish I didn't have to spend time checking my
> > bug mail just to make sure that well-intentioned but mistaken triagers
> > aren't taking items off my to-do list that I want to stay there.
> 
> Something appears to have flagged all inactive bugs as invalid. Apart 
> from generating a ridiculous quantity of email for no obviously good 
> reason, a pile of perfectly valid wishlist bugs or issues that require 
> further work in the rest of the distribution first have suddenly closed. 
> Who on earth thought that this was a good idea?
> 
> -- 
> Matthew Garrett | [EMAIL PROTECTED]
> 


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Matthew Garrett]

On Thu, Sep 20, 2007 at 12:58:25PM +0100, Colin Watson wrote:

> I agree entirely. What drives *me* batty in turn is when people take a
> confirmed, complete report, ask why it hasn't been fixed yet, and close
> it as invalid because obviously something that's been around for a
> couple of releases can't be relevant any more. Or when people reject
> perfectly valid and complete wishlist bugs (note that it usually takes a
> lot less for a wishlist bug to be complete) because they should be
> specifications (they shouldn't, in most cases) or just because they're
> wishlist. As a developer, I wish I didn't have to spend time checking my
> bug mail just to make sure that well-intentioned but mistaken triagers
> aren't taking items off my to-do list that I want to stay there.

Something appears to have flagged all inactive bugs as invalid. Apart 
from generating a ridiculous quantity of email for no obviously good 
reason, a pile of perfectly valid wishlist bugs or issues that require 
further work in the rest of the distribution first have suddenly closed. 
Who on earth thought that this was a good idea?

-- 
Matthew Garrett | [EMAIL PROTECTED]

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Markus Hitter]

Am 20.09.2007 um 12:57 schrieb Aaron Whitehouse:

> Do we really gain anything by having a dev look at "Ubuntu doesn't  
> work" every day for the rest of all time?

If the dev has to look at the unchanged bug each day, there's  
something wrong with filtering/sorting tools.

> My underlying point is that we all want Ubuntu to be bug-free. It
> isn't and it isn't likely to be any time soon. While it isn't, we need
> to focus our resources on things that are ready to be fixed.

Sure. Perhaps the root of the discussion is, many people understand a  
lot of open bugs equals a lot of adminstrative work. I don't see a  
relation here.

I'm no dev but an occasional commiter (to several OSs, including  
fixes) and my understanding is, devs' typical administrative work is  
to have a look at freshly commited bugs and at those with new info  
commited. No need to bother even a second with longstanding  
unchanged, but open bugs.


> There is nothing to stop having people trying to complete  
> INCOMPLETE bugs by
> asking questions, but confirmed, complete reports need to be the  
> priority.

Sounds a lot like Torvalds' "contents != files", leading to the  
development of git. If you want complete bugs to have priority,  
please don't try to blame commiters or grandmothers or numbers  
overwhelmig your imagination, but give priority to these bugs. Make  
sure they appear on top of the bug list in your favourite bug  
handling tool and make sure you don't have to waste time with  
incomplete bugs.

How about a priority point score system?

+ 50 points on initial commit

+ 50 points on subsequent commit by non-developer (means activity)

+ 50 points on duplicate found / merged in

- 1 point each day

This way, you can focus on what's urgent but don't have to make  
people feeling bad by closing / ignoring their commitments.


> A big thanks to all the people keeping the bug system going.

Add my thanks as well.


Markus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/





-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Colin Watson]

On Thu, Sep 20, 2007 at 10:57:48PM +1200, Aaron Whitehouse wrote:
> My underlying point is that we all want Ubuntu to be bug-free. It
> isn't and it isn't likely to be any time soon. While it isn't, we need
> to focus our resources on things that are ready to be fixed. There is
> nothing to stop having people trying to complete INCOMPLETE bugs by
> asking questions, but confirmed, complete reports need to be the
> priority.

I agree entirely. What drives *me* batty in turn is when people take a
confirmed, complete report, ask why it hasn't been fixed yet, and close
it as invalid because obviously something that's been around for a
couple of releases can't be relevant any more. Or when people reject
perfectly valid and complete wishlist bugs (note that it usually takes a
lot less for a wishlist bug to be complete) because they should be
specifications (they shouldn't, in most cases) or just because they're
wishlist. As a developer, I wish I didn't have to spend time checking my
bug mail just to make sure that well-intentioned but mistaken triagers
aren't taking items off my to-do list that I want to stay there.

-- 
Colin Watson   [EMAIL PROTECTED]

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Aaron Whitehouse]

> What is the rationale behind skipping closed bugs in a search? I've
> been burned by this in the past.
>
> I can understand why the QA guys or the even developers would want
> this but for a user, who is actually making the effort to not only
> report a bug but to search for dups first, why would they want to
> ignore closed bugs? Closed bugs often contain exactly what that user
> needs - a workaround or a timeline for the fix to be released,

As has already been pointed out, if a user is filing a bug then this
isn't a problem. If you try and file a new bug with summary "broken",
the list suggests bugs that are Fix Released, Invalid etc. If there
are closed, duplicate bugs, they should be suggested by Launchpad when
the user tries to file it.

I file quite a lot of bugs. Now and again I will file a bug and forget
to include something. Most people mark it as Needs Info/incomplete and
explain what is missing. Some give excellent guidance in typing in the
correct commands etc.

It drives me batty when somebody closes the bug. It also drives me
batty when people misunderstand my problem and duplicate it against
something that isn't related. Without people doing these things,
however, the rest of my bugs would not get fixed as quickly.

We are lucky enough to have a wide range of skills in Ubuntu
volunteers. A few have the ability to fix the bugs that come up in the
products. More have the ability to help people refine their bugs. When
a dev gets home from work and sits in front of their computer for a
couple of hours helping Ubuntu, the bugs need to be ready with
everything that they need.

Lets take an extreme example. Say my mother has an obscure set-up and
her machine doesn't boot at all with Ubuntu. She files a bug saying
"Ubuntu doesn't work". Now, in an ideal world, a triager will help her
through turning that into a detailed report with logs, step-by-step
reproduction instructions etc. But say that the world isn't ideal. Mum
decides Ubuntu is silly and goes back to Microsoft, never looking at
Ubuntu or Launchpad again. Do we really gain anything by having a dev
look at "Ubuntu doesn't work" every day for the rest of all time? How
about 50,000 "Ubuntu doesn't work"s?

There has been excellent progress in projects like
AutomatedCrashReporting. Things like that make it easier for people to
give useful information when they aren't computer literate.

We have too many bugs and not enough people able to fix them. Those
people should be focusing on well-documented, prioritised bugs. If we
ever have more developers than bugs, we can afford to have the
developers chasing people and having incomplete bugs open.

I suppose:
1) When I (as a fairly competent user) file a bug, I need to make sure
that I give all the information that I can;
2) When people are triaging, they should probably try to get the
information that is needed from the reporter before they close the
bug;
3) We could free up the people doing these mundane tasks:
[RFE] Malone should email, then close bugs for inactivity
https://bugs.launchpad.net/malone/+bug/141199
and
[RFE] Email inactive bugs a month after a release
https://bugs.launchpad.net/malone/+bug/141202
and then the people that were doing those tasks could instead help
people complete their reports; and
4) If your bug is a duplicate of a bug that isn't complete, complete it!

A great start would be:
Allow product-/package-specific bug-reporting guidelines
https://bugs.launchpad.net/malone/+bug/43893
as it should dramatically improve report quality. I've been using
Ubuntu since Hoary, but I still don't know when developers will want
the output of lspci etc.

My underlying point is that we all want Ubuntu to be bug-free. It
isn't and it isn't likely to be any time soon. While it isn't, we need
to focus our resources on things that are ready to be fixed. There is
nothing to stop having people trying to complete INCOMPLETE bugs by
asking questions, but confirmed, complete reports need to be the
priority.

A big thanks to all the people keeping the bug system going.

Aaron

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Hugo Heden]

On Tue, 18 Sep 2007 19:13:44 +0200, "Markus Hitter" <[EMAIL PROTECTED]>
said:
> 
> Am 17.09.2007 um 17:44 schrieb Sarah Hobbs:
> 
> > There is simply no way to deal with the current lot of open bugs,  
> > to get
> > an overview of them all, let alone having the invalid ones in there -
> > the problem gets too great, and you can't solve any of it (and become
> > very demotivated in the process).
> 
> You pretty much ask users to stop filing bugs. If a user can provide  
> all information needed, he can track down the problem him self, so a  
> bug database would melt down to a helpdesk for willing and  
> experienced developers.
> 
> Each bug filed contains a snippet of information, at least "something  
> doesn't work here". Each bug closed because of incompleteness says "I  
> ignore your work" to the filing person. Unless you redefine "closed"  
> from "problem solved" to "no interest in working on the problem", of  
> course.

I don't completely agree. As an occasional bug-reporter, I would say the
following:

If the bug state is changed to incomplete, but instructions are provided
for the reporter on how to proceed to make the bug complete/useful, then
I'm all good.

(If the triager cannot provide such instructions for some reason though,
say lack of time, then I'm not sure what would be the best course of
action.)

Best regards

Hugo Heden

> 
> As for the solution - missing resources are a pretty bad excuse to  
> throw away user's contributions. There is no way but to sort the mess  
> and perhaps to refine the search tools.
> 
> 
> Perhaps this is slightly overexposed, but so far my european 2 cent.
> 
> Markus
> 
> - - - - - - - - - - - - - - - - - - -
> Dipl. Ing. Markus Hitter
> http://www.jump-ing.de/
> 
> 
> 
> 
> 
> -- 
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

-- 
http://www.fastmail.fm - The professional email service


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Brian Murray]

On Tue, Sep 18, 2007 at 10:11:49AM +0200, Reinhard Tartler wrote:
> Sarah Hobbs <[EMAIL PROTECTED]> writes:
> 
> > As one of those who triages various KDE bugs...in the area of KDEBase,
> > in particular, there are around 450 open bugs, we *have* to close
> > invalid bugs.  There are around 750, with the INVALID and WONTFIX bugs
> > included.
> 
> Please correct me, but I suspect that when you mean "we have to close
> invalid bugs", I think you actually mean "we need to filter out those
> incomplete bugs which we don't have the ressources for investiagting
> further from 'our' 'default' bug listings". (YMMV of course what is
> "your default" bug listing.
> 
> I think tags could help you here, right?

One tag that I have been using is 'needs-devrelease-testing'.  My
thought was that this tag would identify bugs that there is enough
information to try and reproduce them or that requires specific
hardware, but the original reporter has not given enough information for 
someone to debug the problem.

-- 
Brian Murray @ubuntu.com


signature.asc
Description: Digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Markus Hitter]

Am 17.09.2007 um 17:44 schrieb Sarah Hobbs:

> There is simply no way to deal with the current lot of open bugs,  
> to get
> an overview of them all, let alone having the invalid ones in there -
> the problem gets too great, and you can't solve any of it (and become
> very demotivated in the process).

You pretty much ask users to stop filing bugs. If a user can provide  
all information needed, he can track down the problem him self, so a  
bug database would melt down to a helpdesk for willing and  
experienced developers.

Each bug filed contains a snippet of information, at least "something  
doesn't work here". Each bug closed because of incompleteness says "I  
ignore your work" to the filing person. Unless you redefine "closed"  
from "problem solved" to "no interest in working on the problem", of  
course.

As for the solution - missing resources are a pretty bad excuse to  
throw away user's contributions. There is no way but to sort the mess  
and perhaps to refine the search tools.


Perhaps this is slightly overexposed, but so far my european 2 cent.

Markus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/





-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Fergal Daly]

On 18/09/2007, Henrik Nilsen Omma <[EMAIL PROTECTED]> wrote:
> Reinhard Tartler wrote:
> > Sarah Hobbs <[EMAIL PROTECTED]> writes:
> >
> >
> >> As one of those who triages various KDE bugs...in the area of KDEBase,
> >> in particular, there are around 450 open bugs, we *have* to close
> >> invalid bugs.  There are around 750, with the INVALID and WONTFIX bugs
> >> included.
> >>
> >
> > Please correct me, but I suspect that when you mean "we have to close
> > invalid bugs", I think you actually mean "we need to filter out those
> > incomplete bugs which we don't have the ressources for investiagting
> > further from 'our' 'default' bug listings". (YMMV of course what is
> > "your default" bug listing.
>
> How would that be better from the user's perspective? If everyone who is
> working on the receiving end of bugs (triagers and developers) filter
> out these bugs they will just be silently ignored forever. I'm not sure
> that gives a better impression.
>
> Instead of 'Ubuntu has 30.000 open bugs' we would have 'Ubuntu has
> 60.000 open bugs, many of which are being actively ignored'.

The reality is the same either way. If there is a way of changing
terminology and workflow that makes life no harder for QA and
developers but make it easier for users to find existing reports of
"their" bug (no matter what state they are in) then it should be
investigated,

F

> Henrik
>
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Henrik Nilsen Omma]

Reinhard Tartler wrote:
> Sarah Hobbs <[EMAIL PROTECTED]> writes:
>
>   
>> As one of those who triages various KDE bugs...in the area of KDEBase,
>> in particular, there are around 450 open bugs, we *have* to close
>> invalid bugs.  There are around 750, with the INVALID and WONTFIX bugs
>> included.
>> 
>
> Please correct me, but I suspect that when you mean "we have to close
> invalid bugs", I think you actually mean "we need to filter out those
> incomplete bugs which we don't have the ressources for investiagting
> further from 'our' 'default' bug listings". (YMMV of course what is
> "your default" bug listing.

How would that be better from the user's perspective? If everyone who is 
working on the receiving end of bugs (triagers and developers) filter 
out these bugs they will just be silently ignored forever. I'm not sure 
that gives a better impression.

Instead of 'Ubuntu has 30.000 open bugs' we would have 'Ubuntu has 
60.000 open bugs, many of which are being actively ignored'.

Henrik


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Reinhard Tartler]

Sarah Hobbs <[EMAIL PROTECTED]> writes:

> As one of those who triages various KDE bugs...in the area of KDEBase,
> in particular, there are around 450 open bugs, we *have* to close
> invalid bugs.  There are around 750, with the INVALID and WONTFIX bugs
> included.

Please correct me, but I suspect that when you mean "we have to close
invalid bugs", I think you actually mean "we need to filter out those
incomplete bugs which we don't have the ressources for investiagting
further from 'our' 'default' bug listings". (YMMV of course what is
"your default" bug listing.

I think tags could help you here, right?

> There is simply no way to deal with the current lot of open bugs, to get
> an overview of them all, let alone having the invalid ones in there -
> the problem gets too great, and you can't solve any of it (and become
> very demotivated in the process).

I agree that you that handling packages with tons of bugs is a real
pain. Perhaps the launchpad artists have ideas how to solve this in an
elegant fashion?

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


pgpG9G1aaS8Gh.pgp
Description: PGP signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Sarah Hobbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

As one of those who triages various KDE bugs...in the area of KDEBase,
in particular, there are around 450 open bugs, we *have* to close
invalid bugs.  There are around 750, with the INVALID and WONTFIX bugs
included.

There is simply no way to deal with the current lot of open bugs, to get
an overview of them all, let alone having the invalid ones in there -
the problem gets too great, and you can't solve any of it (and become
very demotivated in the process).

Just my AUD $0.02

Hobbsee
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG7qDu7/o1b30rzoURAn/kAKDsqfdUAQ7YaI+1bb4NA4wSd1oxcgCdFZaS
3hsxCXDhMM2YfaKO3ypZqTA=
=DRYI
-END PGP SIGNATURE-

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Reinhard Tartler]

"Fergal Daly" <[EMAIL PROTECTED]> writes:

> On 12/09/2007, Onno Benschop <[EMAIL PROTECTED]> wrote:
>>2. While Dapper isn't the bleeding edge of Ubuntu, code that exists
>>   in Dapper exists in Feisty and Gutsy today. That implies that bugs
>>   that exist in Dapper are also likely to exist. Disk space is
>>   cheap. A computer is great at searching stuff. Leave the bug in
>>   the system, leave it open so others can stumble upon it and not
>>   feel that they are the first to experience this problem. Debugging
>>   is as much about writing code as it is about the "ah-ha" moment in
>>   which someone determines the cause of the problem.
>
> What is the rationale behind skipping closed bugs in a search? I've
> been burned by this in the past.
>
> I can understand why the QA guys or the even developers would want
> this but for a user, who is actually making the effort to not only
> report a bug but to search for dups first, why would they want to
> ignore closed bugs? Closed bugs often contain exactly what that user
> needs - a workaround or a timeline for the fix to be released,

I think this is a very interesting question. Are there any (publicy
viewable) specs which explain the various use cases for querying bugs?

If the default bug listing wouldn't skip bugs with states 'wontfix' and
'invalid', (I think) there would be fewer temptation to overagressively
set a bug from 'incomplete' to 'invalid'.

(and btw, If the bug listing was configurable per user, I'd probably
even skip 'incomplete' bugs by default for myself. However I agree that
this should not be the default).

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[liam321]

On Mon, 17 Sep 2007 10:27:49 +0100, "Fergal Daly" <[EMAIL PROTECTED]>
said:
> On 12/09/2007, Onno Benschop <[EMAIL PROTECTED]> wrote:
> >2. While Dapper isn't the bleeding edge of Ubuntu, code that exists
> >   in Dapper exists in Feisty and Gutsy today. That implies that bugs
> >   that exist in Dapper are also likely to exist. Disk space is
> >   cheap. A computer is great at searching stuff. Leave the bug in
> >   the system, leave it open so others can stumble upon it and not
> >   feel that they are the first to experience this problem. Debugging
> >   is as much about writing code as it is about the "ah-ha" moment in
> >   which someone determines the cause of the problem.
> 
> What is the rationale behind skipping closed bugs in a search? I've
> been burned by this in the past.
> 
> I can understand why the QA guys or the even developers would want
> this but for a user, who is actually making the effort to not only
> report a bug but to search for dups first, why would they want to
> ignore closed bugs? Closed bugs often contain exactly what that user
> needs - a workaround or a timeline for the fix to be released,
> 
> F
> 

Yes, yes, yes. As a sometimes-bug-filing-user, I would just like to just
underline the above. Thanks Fergal.

Best Regards

Hugo Heden


-- 
http://www.fastmail.fm - IMAP accessible web-mail


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Fergal Daly]

On 12/09/2007, Onno Benschop <[EMAIL PROTECTED]> wrote:
>2. While Dapper isn't the bleeding edge of Ubuntu, code that exists
>   in Dapper exists in Feisty and Gutsy today. That implies that bugs
>   that exist in Dapper are also likely to exist. Disk space is
>   cheap. A computer is great at searching stuff. Leave the bug in
>   the system, leave it open so others can stumble upon it and not
>   feel that they are the first to experience this problem. Debugging
>   is as much about writing code as it is about the "ah-ha" moment in
>   which someone determines the cause of the problem.

What is the rationale behind skipping closed bugs in a search? I've
been burned by this in the past.

I can understand why the QA guys or the even developers would want
this but for a user, who is actually making the effort to not only
report a bug but to search for dups first, why would they want to
ignore closed bugs? Closed bugs often contain exactly what that user
needs - a workaround or a timeline for the fix to be released,

F

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Colin Watson]

On Wed, Sep 12, 2007 at 01:29:10PM +1200, Matthew Paul Thomas wrote:
> What's most important is making the best use of developer time. That in 
> turn requires making the best use of QA time, because an efficient QA 
> team will be more likely to convey accurately which bugs developers 
> should be working on.
> 
> So the QA team need to balance the probability that aggressively 
> declining incomplete bug reports will lead to more duplicates being 
> reported, against the probability that leaving bug reports open will 
> make searching harder and slow down QA in general.

You're omitting the probability that aggressively declining
perhaps-incomplete bug reports will cause bug reporters to get a bad
impression of the clue levels of the Ubuntu team, and make a noise about
Ubuntu's inability to recognise a bug report when they see one. (Note
that many bug reports closed on the basis that they are incomplete are
not in fact incomplete.)

-- 
Colin Watson   [EMAIL PROTECTED]

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[David MacKinnon]

On 9/13/07, Brian Murray <[EMAIL PROTECTED]> wrote:

> As Matthew Paul Thomas mentioned in a different e-mail it is important
> to make efficient use of the QA team.  While having a lot of bugs in the
> "Incomplete" state would be one way of dealing with bugs with
> insufficient information, it would create more "noise" in that there

So looking on from the sidelines, this seems like a prime use-case for
a "Needs more Information" state that continues to turn up in the
default user search (but the QA team can by and large ignore)

-David

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Brian Murray]

On Wed, Sep 12, 2007 at 06:57:28AM +0800, Onno Benschop wrote:
> It is good that you raise this issue in my opinion. I too have seen this
> kind of behaviour and wondered what to do about it. I wondered if adding
> a comment to the bug would help, but found no particularly transparent
> or productive way to engage the person closing the bug.

The Ubuntu kernel team has specified that certain minimum bug 
requirements be met[0] for a bug report regarding their packages -
linux-source-2.6.15 in this case.  The particular bug report mentioned 
did not meet the kernel team's minimum requirements and subsequently was 
closed.  As they are most familiar with the kernel and the maintainer 
of those packages I think it is important to follow their guidelines.

> I'm almost wondering if it's happening because you get karma from
> closing a bug.

Personally, I am not closing bugs to gain karma.  I am employed by
Canonical to improve the quality of Ubuntu especially via its bug 
reports.  Additionally, as far as I know you can't do anything with 
Launchpad karma.  
 
> From my perspective, closing a bug like this adds to the workload
> because now there needs to be effort in combining and locating duplicate
> bugs, some of which have been closed like this. It makes the overall
> bug-list smaller, but it does in my opinion not create a better signal
> to noise ratio. I have seen cases where the combined mass of partial
> information was enough to locate the source of a bug.

As Matthew Paul Thomas mentioned in a different e-mail it is important
to make efficient use of the QA team.  While having a lot of bugs in the
"Incomplete" state would be one way of dealing with bugs with
insufficient information, it would create more "noise" in that there 
would be more bug reports in the QA team's queue which are not
particularly useful.  Also as I mentioned in my other e-mail the fact 
that the bug is Invalid does not delete it from Malone or hide it from 
all search results.  Furthermore, there is nothing to prevent someone 
from combining multiple partial Invalid bugs into a complete Confirmed
one.

[0] https://wiki.ubuntu.com/KernelTeamBugPolicies

-- 
Brian Murray @ubuntu.com


signature.asc
Description: Digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Brian Murray]

On Wed, Sep 12, 2007 at 07:06:29AM +0800, Onno Benschop wrote:
> That is fine if the bug is likely to be a one-off-non-repeatable
> offender, like say a corrupt file on a file system that has been
> erased
> and reformatted. But I don't think that this bug is in that class.
> Having a bug like this closed means there is little chance for casual
> visitors to stumble on the bug and link the report to the behaviour
> they're seeing.

The fact that the bug is Invalid does not mean that the bug does not
show up for a casual visitor to Launchpad.  I would imagine this casual
visitor would submit a new bug report and that process shows you Invalid
bugs.  I tested this by submitting a new bug report about the
linux-source-2.6.15 package with prism54 in the subject and quite a few
Invalid bug reports showed up in the "Is the bug you're reporting one of
these?" dialog.

> Most of my personal linux troubleshooting revolves around googling for
> output seen on syslog. With a closed bug like the one Alexandre showed
> us, do not show up as far as I know.

I don't think that Google would selectively index bug reports based on
their state.  You should be able to craft a Google search using 
something like "site:launchpad.net inurl:bugs intitle:Bug" and a search 
string to prove this.  While slightly contrived I used a specific bug 
number, 112283, which is currently Invalid and it showed up in Google.

-- 
Brian Murray @ubuntu.com


signature.asc
Description: Digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Jonathan Jesse]

On Wednesday 12 September 2007 03:19:17 Alexandre Strube wrote:
> 2007/9/12, Matthew Paul Thomas <[EMAIL PROTECTED]>:
>
> A bug report takes up exactly the same amount of disk space regardless
>
> > of whether it is open or closed.
> >
> > What's most important is making the best use of developer time. That in
> > turn requires making the best use of QA time, because an efficient QA
> > team will be more likely to convey accurately which bugs developers
> > should be working on.
> >
> > So the QA team need to balance the probability that aggressively
> > declining incomplete bug reports will lead to more duplicates being
> > reported, against the probability that leaving bug reports open will
> > make searching harder and slow down QA in general.
>
> Matthew,
> there are important bugs not being fixed from version to version, but
> instead being closed.
>
> A new release that doesn't fix a bug must not close the bug just because it
> was posted a long time ago or because the OP is not a debugging expert.
> This generates two things:
>
> - Other people will report it again. Newer reports are not necessairily
> better than a "mee too" with more detail on a bug.
>
> - Frustration, as the poster will not find the same error with other
> people, and waste time looking if the problem is his.
>
> I've passed through both situations recently. One for a prism54 hardware,
> where the bug was recently closed on hardware. The kernel reported that my
> hardware is faulty as soon as I upgraded from feisty to gutsy. Damn, how
> can it be faulty? I just used it to download the 700mb+ of the upgrade!
>
> Then, I searched for the bug on launchpad and nothing. Lacking a cd to
> reinstall Ubuntu (and no network on ubuntu anymore), I installed a windows
> just to be able to test the prism54 card again.
>
> The card worked perfectly. I then went to launchpad again (about three
> hours later) to submit the bug. When I submitted, I found a similar one,
> closed.
>
> This is what I call frustration...


As a member of -QA that close bugs with no response how would you then argue 
dealing with the bug if the person is not responding.  I have closed several 
bugs with no resposne because I wasn't seeing the bug on my system, but that 
might have been because the bug was fixed by an update and the reporter just 
hasn't updated the status of the bug.

I think to help this is if there was some way to set a "reminder" email if the 
reporter would want to subscribe to a bug, they get an email after X days of 
no update saying "there was a bug reported by you, was it fixed?" or 
something like that.

I've closed plenty of bugs because of no response from the orginial reporter 
and hope we continue.  this trims down the list of bugs that are actually 
bugs.

JOnathan

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Alexandre Strube]

2007/9/12, Matthew Paul Thomas <[EMAIL PROTECTED]>:

A bug report takes up exactly the same amount of disk space regardless
> of whether it is open or closed.
>
> What's most important is making the best use of developer time. That in
> turn requires making the best use of QA time, because an efficient QA
> team will be more likely to convey accurately which bugs developers
> should be working on.
>
> So the QA team need to balance the probability that aggressively
> declining incomplete bug reports will lead to more duplicates being
> reported, against the probability that leaving bug reports open will
> make searching harder and slow down QA in general.



Matthew,
there are important bugs not being fixed from version to version, but
instead being closed.

A new release that doesn't fix a bug must not close the bug just because it
was posted a long time ago or because the OP is not a debugging expert. This
generates two things:

- Other people will report it again. Newer reports are not necessairily
better than a "mee too" with more detail on a bug.

- Frustration, as the poster will not find the same error with other people,
and waste time looking if the problem is his.

I've passed through both situations recently. One for a prism54 hardware,
where the bug was recently closed on hardware. The kernel reported that my
hardware is faulty as soon as I upgraded from feisty to gutsy. Damn, how can
it be faulty? I just used it to download the 700mb+ of the upgrade!

Then, I searched for the bug on launchpad and nothing. Lacking a cd to
reinstall Ubuntu (and no network on ubuntu anymore), I installed a windows
just to be able to test the prism54 card again.

The card worked perfectly. I then went to launchpad again (about three hours
later) to submit the bug. When I submitted, I found a similar one, closed.

This is what I call frustration...

-- 
[]
Alexandre Strube
[EMAIL PROTECTED]
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Matthew Paul Thomas]

On Sep 12, 2007, at 11:06 AM, Onno Benschop wrote:

...
   2. While Dapper isn't the bleeding edge of Ubuntu, code that exists
  in Dapper exists in Feisty and Gutsy today. That implies that
  bugs that exist in Dapper are also likely to exist. Disk space is
  cheap. A computer is great at searching stuff. Leave the bug in
  the system, leave it open so others can stumble upon it and not
  feel that they are the first to experience this problem.
...


A bug report takes up exactly the same amount of disk space regardless 
of whether it is open or closed.


What's most important is making the best use of developer time. That in 
turn requires making the best use of QA time, because an efficient QA 
team will be more likely to convey accurately which bugs developers 
should be working on.


So the QA team need to balance the probability that aggressively 
declining incomplete bug reports will lead to more duplicates being 
reported, against the probability that leaving bug reports open will 
make searching harder and slow down QA in general.


Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/


PGP.sig
Description: This is a digitally signed message part
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Onno Benschop]

On 12/09/07 06:41, Henrik Nilsen Omma wrote:
> Alexandre Strube wrote:
>   
>> I want to raise something here...
>>
>> One of the things that made me take some distance from daily ubuntu 
>> development was a raid of newer people which closes the bugs for 
>> whatever reason. If the bug is not good enough for them, they close. 
>> This is more or less an example:
>>
>> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/43354 
>> 
>>
>>
>> yes, the guy did not provide the information required. Does this mean 
>> that the bug vanished magically? No. In fact, the prism54 status is 
>> REGRESSION from feisty to gutsy. But why would I bother to post a bug, 
>> just to be closed for any reason? (This is only an example. There are 
>> several others)
>> 
>
> I see no mention of Gutsy on that bug, only Dapper. We have to focus on 
> the bugs that have a good chance of being fixed because there are so 
> many reports. That generally means bugs that are confirmed in the 
> development release and have the relevant info attached.
>   
Henrik,

On the face of it your argument is solid, but there are two things that
you do not appear to take into consideration.

   1. Dapper is an LTS release and bugs related to it should be treated
  in a similar fashion to a development release in my opinion. That
  is, they have a higher priority than an Edgy bug.
   2. While Dapper isn't the bleeding edge of Ubuntu, code that exists
  in Dapper exists in Feisty and Gutsy today. That implies that bugs
  that exist in Dapper are also likely to exist. Disk space is
  cheap. A computer is great at searching stuff. Leave the bug in
  the system, leave it open so others can stumble upon it and not
  feel that they are the first to experience this problem. Debugging
  is as much about writing code as it is about the "ah-ha" moment in
  which someone determines the cause of the problem.


> Brian did explicitly write "please reopen it if you can give us the 
> missing information", which seems fair. The submitter gets another 
> reminder of the outstanding bug as it's closed. It may result in a few 
> new bugs being submitted as issues are discovered by other people, but 
> then it's more likely to be tested on a more recent version.
>   
That is fine if the bug is likely to be a one-off-non-repeatable
offender, like say a corrupt file on a file system that has been erased
and reformatted. But I don't think that this bug is in that class.
Having a bug like this closed means there is little chance for casual
visitors to stumble on the bug and link the report to the behaviour
they're seeing.

Most of my personal linux troubleshooting revolves around googling for
output seen on syslog. With a closed bug like the one Alexandre showed
us, do not show up as far as I know.


-- 
Onno Benschop

Connected via Optus B3 at S31°54'06" - E115°50'39" (Yokine, WA)
--
()/)/)()..ASCII for Onno..
|>>?..EBCDIC for Onno..
--- -. -. ---   ..Morse for Onno..

ITmaze   -   ABN: 56 178 057 063   -  ph: 04 1219    -   [EMAIL PROTECTED]


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Onno Benschop]

On 12/09/07 04:39, Alexandre Strube wrote:
> I want to raise something here...
>
> One of the things that made me take some distance from daily ubuntu
> development was a raid of newer people which closes the bugs for
> whatever reason. If the bug is not good enough for them, they close.
> This is more or less an example:
>
> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/43354
> 
>
>
> yes, the guy did not provide the information required. Does this mean
> that the bug vanished magically? No. In fact, the prism54 status is
> REGRESSION from feisty to gutsy. But why would I bother to post a bug,
> just to be closed for any reason? (This is only an example. There are
> several others)
Alexandre,

It is good that you raise this issue in my opinion. I too have seen this
kind of behaviour and wondered what to do about it. I wondered if adding
a comment to the bug would help, but found no particularly transparent
or productive way to engage the person closing the bug.

I'm almost wondering if it's happening because you get karma from
closing a bug.

>From my perspective, closing a bug like this adds to the workload
because now there needs to be effort in combining and locating duplicate
bugs, some of which have been closed like this. It makes the overall
bug-list smaller, but it does in my opinion not create a better signal
to noise ratio. I have seen cases where the combined mass of partial
information was enough to locate the source of a bug.

A better approach in my opinion would be to mark the bug as "needs info"
and leave it alone.

-- 
Onno Benschop

Connected via Optus B3 at S31°54'06" - E115°50'39" (Yokine, WA)
--
()/)/)()..ASCII for Onno..
|>>?..EBCDIC for Onno..
--- -. -. ---   ..Morse for Onno..

ITmaze   -   ABN: 56 178 057 063   -  ph: 04 1219    -   [EMAIL PROTECTED]


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: That need to close bugs?

[Henrik Nilsen Omma]

Alexandre Strube wrote:
> I want to raise something here...
>
> One of the things that made me take some distance from daily ubuntu 
> development was a raid of newer people which closes the bugs for 
> whatever reason. If the bug is not good enough for them, they close. 
> This is more or less an example:
>
> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/43354 
> 
>
>
> yes, the guy did not provide the information required. Does this mean 
> that the bug vanished magically? No. In fact, the prism54 status is 
> REGRESSION from feisty to gutsy. But why would I bother to post a bug, 
> just to be closed for any reason? (This is only an example. There are 
> several others)

I see no mention of Gutsy on that bug, only Dapper. We have to focus on 
the bugs that have a good chance of being fixed because there are so 
many reports. That generally means bugs that are confirmed in the 
development release and have the relevant info attached.

Brian did explicitly write "please reopen it if you can give us the 
missing information", which seems fair. The submitter gets another 
reminder of the outstanding bug as it's closed. It may result in a few 
new bugs being submitted as issues are discovered by other people, but 
then it's more likely to be tested on a more recent version.

Henrik

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss