Comment 1 for bug 90738
Revision history for this message
| Matthew Paul Thomas (mpt) wrote Re: Standard search fails to find bugs marked 'Fix released' | #1 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
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:/
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:/