[Libreoffice-qa] Closing bugs in bugzilla: fixed in master or fixed everywhere?

Michael Stahl mstahl at redhat.com
Wed Sep 5 03:38:35 PDT 2012

On 05/09/12 10:46, Lionel Elie Mamane wrote:
> I'd like to check if maybe I misunderstood our bugzilla handling
> standards.
> I thought we close the bug when the fix is committed in all branches
> where it should be, and that's what I was doing in the bugs I was
> fixing.
> But obviously, if our community standards are the other way round,
> I'll follow them.
> I asked because I have now lived several times now that several
> developers close a bug I'm CCed to as soon as they commit the fix to
> master.
> The disadvantage of the latter method is that these bugs appear
> crossed out in the "most annoying" (and other) lists.
> Its advantage, maybe, is that it goes away from said developer's
> list: their job is "finished" so it should get the hell out of their
> TODO list.

the fundamental problem is that bugzilla has a single "FIXED" state,
which is insufficient for our workflow; it should have one FIXED-x.y for
every release, so that this can be tracked properly (iirc LaunchPad
works that way).

if you set the bug to FIXED after the fix is in master, then people will
get confused because they will assume that the fix is already in the
release branch when it is not.

if you set the bug to FIXED after it is on all branches, then people
will get confused because they will assume that whatever was committed
to master doesn't fully fix the bug (a partial fix?), which is not
actually an unrealistic scenario.

currently i set the FIXED after the fix is in master, because we already
have an approximation of the FIXED-x.y states via the target:x.y
whiteboard field; those familiar with our bugzilla process will
interpret the combination of status and whiteboard target entries correctly.

> I've come to see this last point as not completely obvious, and maybe
> even wrong: when I commit a fix to master, I regard it as also my job
> to get it backported to the other branches, so my job on this bug is
> _not_ finished, so it makes sense for it to linger in my TODO list
> until the fix is everywhere it should.

yes, but we track the fix backport proposals in gerrit (or via the
legacy mechanism: mailing list), we have never used bugzilla for that.

More information about the Libreoffice-qa mailing list