That need to close bugs?
Matthew Paul Thomas
mpt at canonical.com
Thu Sep 27 03:07:15 UTC 2007
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 at esatclear.ie> 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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20070927/e23aecfa/attachment.sig>
More information about the Ubuntu-devel-discuss
mailing list