Update: this is sadly not as easy technically as it should be (e.g. Bugzilla 3.6 has several hard-coded status names lurking in the code). This is definitely not happening on Tuesday, and may have to wait until we upgrade to 4.0. <sigh>.
Next Tuesday, 9th November When we upgrade to Bugzilla 4.0, the values of the Status field in bugzilla.mozilla.org are changing, as discussed in mozilla.dev.planning. This is to match us up with upstream changes, make it more clear what each state means, and to clarify which bugs are the responsibility of QA and which of Dev.
The changes are as follows:
- NEW will be rename to CONFIRMED, so all existing bugs change
- ASSIGNED will be renamed to IN_PROGRESS, ditto
- READY_TO_FIX is a new state (see below)
- REOPENED will be removed (reopened bugs go straight to CONFIRMED or IN_PROGRESS)
So the Statuses and their meanings will be as follows:
| Status | Meaning | Responsible |
|---|---|---|
| UNCONFIRMED | not confirmed; filed by inexperienced reporter | QA |
| CONFIRMED | can reproduce, not an obvious dupe | QA |
| READY_TO_FIX | has appropriate QA/UX work complete, ready for a developer | Dev |
| IN_PROGRESS | developer is working on a patch | Dev |
| RESOLVED | patch has been committed to trunk | QA |
| VERIFIED | fix has been QAed in builds | n/a |
Will saved searches change over to the new structure as well, or will these have to be rebuilt?
Reporters of bugs are users too. The biggest issue with the status field is that RESOLVED has no meaning for users and VERIFIED is very unlikely to hit. So when we receive the email that the bug is fixed, we know that some time in the future we can enjoy the fix, but we don’t know when that will be and we won’t get any more emails on the bug to remind us to try. This leads to endless, tedious posts to bugs “Has this been fixed?” “This still does not work” etc. To me, a bug is not resolved if the reporter has no practical way to access the fix.
johnjbarton: A long time ago, Bugzilla had a CLOSED state, which originally meant something like “this fix has now shipped to the public”. However, it was so little used that it got removed. I note the problem you raise, but I don’t think a new status will fix it.
Gerv
I’m glad that you’re doing this. Bugzilla 4 has some really great changes.
Can you clarify exactly what happens before transitioning to READY_TO_FIX? UX work I can understand, for feature requests or bugs that necessitate UI changes; might as well hammer out the details, prototypes, and bikeshedding before a developer bothers to code it. (Though the new state does seem to preempt the possibility of a developer resolving that discussion by coding a working solution, a classic way to settle bikeshedding.) But what QA work needs to happen after agreeing that a bug exists and before fixing it?
My guess would be that the common case that would be a good example for when a bug is confirmed but not ready to fix would be crashes. Bugs get filed about crashes that are being reported via breakpad. But the bug is usually not ready to be fixed until more can be understood about the bug like how to reproduce the crash.
You need some way to show what versions will have the fix. Currently there’s no definitive information, and often no information at all.
johnjbarton and VanillaMozilla: The fix will be in all binaries built on the appropriate source branch after the fix landed. This means that:
– It will be in the next release (on that branch)
– It will be on nightlies (of that branch), usually starting the day after the fix landed
– Anyone in a hurry can install a build from the appropriate tinderbox-builds directory on FTP, starting a few hours at most after the Bugzilla comment mentioning that the fix has landed.
A build will have the fix if (it is from the right source branch and) its “build ID” timestamp is after the date-time when the fix was landed (which is usually shortly before the corresponding bug either is set to FIXED or gets a “fixed-1.9.1” or similar flag). The appropriate tinderbox.mozilla.org page can help you check when any given build was started and completed, without the need to install it. I’ve been using the third (“fastest”) method above whenever there were newly fixed bugs that had seriously bogged me (and after testing that they worked I dutifully reported the fact in order to ease the progress of the bug report to VERIFIED status). Or you can use some extension like MR-Tech Toolkit (or maybe Nightly Tester Tools but I’m less sure about that) to get the full timestamp (down to the second, not to the day as in the User-Agent string) into the clipboard or on your windows’ titles.
All of what I’m saying here (and everything about the RESOLVED and VERIFIED statuses) is unaffected by the new Bugzilla status changes.
Anonymous: it depends on the bug, but if CONFIRMED means “yes, I can reproduce this problem, it’s definitely a problem”, then the distance between there and READY_TO_FIX might involve one or more of: getting more information from the reporter, working out the minimal steps to reproduce, making a testcase, or deciding on the architecture of a solution.
VanillaMozilla: You are right, but that is a different problem. We hope eventually Bugzilla will have support for a mechanism to allow a different status for each branch.
THANKS Gerv, for coordinating this welcome, though not yet in production, set of changes.
> We hope eventually Bugzilla will have support for a
> mechanism to allow a different status for each branch.
If so, you would also want a new status that could be given to a bug on branches where the fix will not be incorporated, something like NOT_FOR_THIS_BRANCH. In principal WONTFIX could work for this, but people would definitely misunderstand that, frequently, and it would cause problems (soak up people’s time explaining it over and over again, if nothing else).
The larger problem, though, would be the UI for displaying (and managing) the list of stati for a given bug. It seems obvious that you would not want to individually list a status for each and every branch throughout the history of the project on each and every bug, so some provision would need to be made for bundling them into ranges. But ranges get wonky when you’re operating on a tree, rather than a line (i.e., when there are branches off of branches)…