On Fri, Mar 09, 2007 at 11:04:04AM -0000, Matthew Paul Thomas wrote:
> When designing the bug statuses, we reasoned that we couldn't show long-
> inactive bug reports in search results by default: that wouldn't scale
> past about five years of use.

While they become less relevant over time, they certainly don't immediately
become irrelevant when they are closed, which is how they're depicted in the
current UI.

Think about this like a search engine; the content is not deleted, and it
should still turn up in search results, appropriately ranked.  Google
doesn't remove a news story from search results just because it's no longer
applicable; it just becomes less relevant.

> But at the same time, we didn't want to hide bugs as soon as they were
> fixed in the development version, because then people experiencing the
> bugs in the release version wouldn't see the fixed bugs when searching, so
> they would report many more duplicates.
> 
> So we established Fix Committed for bugs that were fixed in the
> development version but not in a released version, with the intention that
> Fix Committed bugs be mass-changed to Fix Released when the development
> version was released. A small flaw in this plan was that we never
> implemented mass changes.

That flaw makes the Fix Committed status almost entirely unusable for us, as
I'm sure you understand.  We deal with thousands of bugs during a release,
and it's completely infeasible to update them all when we do release.

> A larger flaw in the plan was that "released" is ambiguous. For Launchpad
> it's fairly simple, because there is only one important installation, with
> code rollouts and cherrypicks marking the transition from Committed to
> Released. But for Ubuntu, should a bug be marked Fix Released when an LTS
> version has the bugfix? A non-LTS version? A beta?  A preview release? We
> didn't discuss this fully with the Ubuntu developers, and it seems as
> though they have taken it to mean "when a fixed package hits the archive".
> As a result, for example,
> <https://launchpad.net/ubuntu/feisty/+bugs?field.status%3Alist=Fix+Released>
> currently shows 16 Fix Released bugs in Feisty, which is impossible
> because Feisty has not been released.

It's also a meaningless subset, because almost none of the bugs affecting
Feisty are targeted at Feisty.  It's just too much bookkeeping for the
common case.

> In the long term perhaps we could replace Fix Committed and Fix Released
> with something both simpler and more flexible (perhaps a single Fixed/Done
> status, plus either some means of recording which version(s) are fixed, or
> some configurable period for which bugs will still show up in bug listings
> after being fixed).

These are both good ideas, and I think they're complementary.  The union of
these is actually pretty close to what debbugs does.

> Other people have other ideas, though
> <https://wiki.ubuntu.com/BugWorkflow>, so Fix Released may be around for a
> while. Perhaps it would be feasible to use the opening of Feisty+1 as a
> date when people should start using "Fix Released" to mean "fixed in an
> Ubuntu release".

BugWorkflow doesn't contradict what I've said here; it's attempting to
address a different problem.  The key issue there is trying to seal over the
crevice between triage and development, where bugs can get lost.

-- 
 - mdz