Bugzilla – Bug 141847
use "fixed in milestone" field when setting a bugreport to FIXED
Last modified: 2009-01-13 00:34:49 UTC
I'm not sure if this is a bugreport about bugzilla or the developers using it ;-) In short: it would be very useful for people searching bugzilla if the "fixed in milestone" field is set in fixed bugs. Unfortunately most developers don't set it :-( Advantages of setting the "fixed in milestone" field: - can be done when setting the bug to "fixed" - not that much "paperwork" for the developers - target milestone is searchable - I can imagine searching for bugs with status "fixed", but "target milestone" greater than my version. (At the moment I just search for bugs in all states, but with the disadvantage of seeing too much outdated bugs.) To make it easier for developers, you could move the "fixed in milestone" field near the "resolve bug, changing resolution to ..." option field - this way it can be accessed faster and cannot be overlooked. Maybe you could make "fixed in milestone" ogligatory when setting bugs to FIXED, but I'm not sure if this is really helpful. At least you should provide a "see bug comments" as possible milestone to be used when the list of milestones does not match (for example, if the fix is a YOU update).
It's against the developers using it ;-) Let's not make this obligatory for now - it's not always that easy. A fix might get submitted to our build system but will not make it for the next beta and therefore it might not be accurate.
(In reply to comment #1) > Let's not make this obligatory for now - it's not always that easy. I said _maybe_ you could make it ogligatory. I did _not_ say you should/must/whatever ;-) What about my suggestion to move the "fixed in milestone" field near the "resolve bug, changing resolution to ..." field? Call it an usability enhancement (because two related fields are nearby then) and hope developers set the target milestone when closing a bug ;-) > A fix might get submitted to our build system but will not make it for the > next beta and therefore it might not be accurate. But it would be much better than "look at the date the bug was closed, fetch a release calendar and look up what release came first after that date ;-)) I understand that a wrong set "target milestone" is not good, but not setting it at all is even worse.
Sorry, Christian, but Andreas obviously doesn't won't to change this. His point is valid since we cannot control the exact time a fix gets through the build system as the performance varies. This would cause more confusion and people would probably start to reopen bugs or file new ones with the claim that this problem is not fixed on their machine. Once a bug is fixed, there will be an update available via YOU or the developer points out for which version the fix/enhancement will be available. If you, however, encounter a problem on your installation that is fixed in bugzilla, you obviously haven't got the patch yet... I'll close it again taking Andreas into CC so he will receive a copy of this. Maby he adds another comment here.