Standard search fails to find bugs marked 'Fix released' / 'invalid' / 'duplicate' / 'wontfix' / 'opinion'

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

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.

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

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

I suppose that a mass-change from Fix Committed to Fix Released, at release time, would be infeasible even if mass changes were implemented in Launchpad. For example, when NoMoreSourcePackages lets bugs be fixed on a mainline during a release's code freeze, not all bugs that happen to be Fix Committed on release day will have their fixes included in the release, and determining the subset that have been included would be too much work (as prefigured by the current dearth of distrorelease bug targeting you mentioned).

I'm unclear about whether you think there is a *useful* distinction between "Fix Committed" and "Fix Released" at all. If so, how would the distinction help in daily work?

On Thu, Mar 22, 2007 at 07:58:41AM -0000, Matthew Paul Thomas wrote:
> I suppose that a mass-change from Fix Committed to Fix Released, at
> release time, would be infeasible even if mass changes were implemented
> in Launchpad. For example, when NoMoreSourcePackages lets bugs be fixed
> on a mainline during a release's code freeze, not all bugs that happen
> to be Fix Committed on release day will have their fixes included in the
> release, and determining the subset that have been included would be too
> much work (as prefigured by the current dearth of distrorelease bug
> targeting you mentioned).
>
> I'm unclear about whether you think there is a *useful* distinction
> between "Fix Committed" and "Fix Released" at all. If so, how would the
> distinction help in daily work?

Fix Committed - To the maintainer, this usually means that the bug doesn't
need any further attention. The fix will be included in the next release
they do, without any further action on their part. They might review the
list of Fix Committed bugs to decide whether there is enough there to
justify rolling a new release, or if they will wait until later. To another
developer, it means that they don't need to concern themselves with this bug
at all, because a fix has already been accepted into the tree. To the user,
it means that the bug is known, and a fix is on the way with the next
version of the package. People still see the bug, but have no reason to
act on it.

Fix Released - The fix has been incorporated into a release, and is believed
to be fully resolved. If anyone sees the bug in the current version, they
should take action and seek to reopen the bug report.

--
 - mdz

I might be misunderstanding you, but those definitions seem to be much the same as those I gave in my first comment -- definitions that Ubuntu is not following because they're impractical, and that I've suggested would still be impractical even if mass changes were implemented. So would you prefer to change (1) the statuses (e.g. merging them into "Done" with a fixed-in-versions field), (2) the definitions of the current statuses (e.g. for "Released" to mean "in the newest development version" rather than "in the latest release"), or (3) the Ubuntu process (with the help of a mass change UI and perhaps a "Date Fixed" bug listing column)?

On Tue, Apr 24, 2007 at 06:08:20AM -0000, Matthew Paul Thomas wrote:
> I might be misunderstanding you, but those definitions seem to be much
> the same as those I gave in my first comment -- definitions that Ubuntu
> is not following because they're impractical, and that I've suggested
> would still be impractical even if mass changes were implemented.

The only reason they're impractical is because Launchpad and Bazaar don't
yet support automating this. My understanding is that this work is planned
for an unspecified time in the future.

> So would you prefer to change (1) the statuses (e.g. merging them into
> "Done" with a fixed-in-versions field), (2) the definitions of the current
> statuses (e.g. for "Released" to mean "in the newest development version"
> rather than "in the latest release"), or (3) the Ubuntu process (with the
> help of a mass change UI and perhaps a "Date Fixed" bug listing column)?

(2) is what we are doing today, though it sounds like the definitions in
Launchpad itself don't match, while we wait for (4) Launchpad automatically
tracks the progress of a fix through Bazaar into the distro, and updates the
bug accordingly.

If (4) isn't going to happen, I'm fine with updating the definitions in
Launchpad, but my understanding is that they're global, and this would upset
Launchpad developers who don't have this ambiguity due to having only one
version of Launchpad in production at a time.

--
 - mdz

I hit this problem (failing to find bugs because they're already fixed). Even though I'm an upstream developer and have the latest trunk code, I'm often interested in bugs that are already fixed.

I have a suggestion: in the search results page, add this link: '%d fixed bugs and %d invalid bugs also match this search', with appropriate hyperlinks. Or just one link that searches regardless of state would be fine. You don't even really need to have the numbers; the link would be enough.

I hit this problem recently (as a ubuntu user):

There was a bug dubbed : "no sound hardy kernel 2.6.24-12" in the ubuntu project.
The bug didn't show up when searching for "no sound hardy" for instance.
This bug has many (52 as of today) duplicates. Half of them (26, as shown by their activity log) where reported after the fix was released (and to make things worse, many were commented on after they were marked as duplicates). This leads to increased email traffic (and noise) and extra work for the maintainers. It seems to be particularly a problem when nearing a release, when testing users are very active and fix are commited quickly. Further more, for big projects like Ubuntu, the fix usually takes some time to hit the mirrors. A solution could be to show "recently fixed" bugs, within a sensible time frame such as 2 or 3 days. However as pointed in a previous comment, this seems unnecessary for small projects or web based projects like launchpad itself since the fix is almost instantly applied. This should ultimately be a project-wise setting.

Fixing bug 28697 would alleviate the problem, but I think Martin's suggestion: "in the search results page, add this link: '%d fixed bugs and %d invalid bugs also match this search', with appropriate hyperlinks" would be even better.

I reported bug 163694 on merging Fix Committed and Fix Released.

This bug just caught me, too.

I'd like to add that even in the advanced search it's not apparent that "Fix committed" is excluded by default.
In #90738 I read that originally "this was intended to cut down on duplicates". But if I experience a bug and then search for similar reports, I will miss these by default if a fix already has been released and I will report a duplicate.

I vote for the proposal of Diogo Matsubara (two comments above here).

This is not properly a duplicate of bug 5977. Bug 5977 is specifically about treating person bug listings differently, whereas this bug report is about bug searches in general.