This posting is part of a series on small and sometimes not-so-easy-to-discover functionality in Bugzilla that makes developers’ and users’ lifes more comfortable. It’s based on conversations with users and developers in the last months.
This episode covers an aspect of release management: Branches.
Bugzilla’s support for tracking bugs and bug fixes in several branches/versions has been notoriously bad.
I have seen two ways how software projects using Bugzilla handle this: One way is to clone bug reports and use the Version and Target Milestone fields strictly. Hence one bug report only affects one branch (version), and the very same bug is handled in a separate bug report for a different branch/version.
Another way is to use flags. Flags can have four states:
- ?: Somebody requested a decision.
- -: The request was refused.
- +: The request was approved.
- By default the field is empty, and no decision is required / the bug report is not affected.
Flags in Wikimedia Bugzilla:
Still, using flags requires agreements on workflows, for example after setting “+” (approved) the bug report should only be closed as RESOLVED FIXED once the fix has actually been merged into the branch.
Since version 4.4, bugmail includes an “X-Bugzilla-Flags” email header which allows filtering mail on it. Furthermore, in contrast to keywords, flags can be configured to automatically notify certain email addresses whenever such a flag request is set.
Mozilla Bugzilla even has a more complicated custom implementation of this which covers both testing whether a version is affected and whether a version has received a bug fix, allowing more than the four states mentioned above:
If you use a different approach to track branches in Bugzilla, let me know in the comments!
