Re: That need to close bugs?

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

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" <fergal@xxxxxxxxxxxx> 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/

Attachment: PGP.sig
Description: This is a digitally signed message part