Re: Closing bugs in bugzilla: fixed in master or fixed everywhere?

On Wed, Sep 05, 2012 at 12:44:58PM +0200, Bjoern Michaelsen wrote:
> On Wed, Sep 05, 2012 at 11:39:04AM +0200, Stephan Bergmann wrote:
> > On 09/05/2012 10:46 AM, Lionel Elie Mamane wrote:

> > > 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.

> > That's my understanding too, setting a bug to RESOLVED/FIXED only
> > once all the relevant commits have reached the intended branches.

> That is quite tricky as "intended branches" is not clearly defined,

How is it "not clearly defined"?

 - Either we want the fix in 3.6.x or we don't.

 - When in the RC phase of 3.6.2, either we want the fix in
   3.6.2.next-rc or not.

 - Either we want the fix in 3.5.x or we don't.

 - When in the RC phase of 3.5.7, either we want the fix in
   3.5.7.next-rc or not.

Once these decisions are taken, the intended branches are fixed:

 - Yes -> libreoffice-3-6

 - Yes -> libreoffice-3-6-2

 - Yes -> libreoffice-3-5

 - Yes -> libreoffice-3-5-7

We can change our opinion on these questions, and then the "intended
branches" set changes.

> and in addition it runs counter to what mozilla defines the RESOLVED state:

>  https://bugzilla.mozilla.org/page.cgi?id=fields.html

Bugzilla has absolutely no clue about multiple development branches,
and this is one of its main flaws.

Even considering this, in the link you give "RESOLVED" is: "A
resolution has been taken, (...)", which to me does not say whether it
is "a resolution has been taken in some branch" or "a resolution has
been taken in all intended branches".

> In our case, as we dont really verify yet, I would suggest the following:

> RESOLVED: assumed to be fixed for some branch, not tested, not yet released

So if you go to https://bugs.freedesktop.org/show_bug.cgi?id=37361 (LO
3.5 MAB), you have to click through on *each* resolved bug to read the
bug log and try to see if there is a "fixed in 3.5.x" comment (or
possibly look in whiteboard for a target:3.5", so that you can
evaluate whether it is still relevant, or if action is needed?
This makes it IMHO too easy for a bug to "slip under the radar" and be
forgotten.

With my / Stephan's way you'd have to click on each *open* bug to get
certainty whether action is needed for 3.5; but each of these bugs has
"action needed for some branch".

I feel less bad about making people reviewing MAB list go to bugs that
need some action, but elsewhere, rather than having to look at all
already handled bugs.

In the ESC call agenda, we have MAB statistics that say e.g.

 * 3.5 most annoying bugs ...
     + 81 open (of 269) older 73/258 73/257 76/256 75/253 77/253 73/250  72/249
        30%                 26%    28%    30%     30%    30%    29%       29%
     + https://bugs.freedesktop.org/showdependencytree.cgi?id=37361&hide_resolved=1

   With your suggestion, this would mean "81 not fixed anywhere", and
   this might be... between 81 and 269 fixed in 3.5.

   With my / Stephan's way, this means "81 not fixed everywhere it
   should", and this might be between 0 and 81 fixed in 3.5.

I prefer to err on the side of caution, that is overreporting the
number of relevant bugs rather than underreproting them.


> CLOSED: there is a version with the fix released

OK with me (and a nice service to our users). Same bikeshedding on
"all intended branches have a version with the fix" or "at least one
branch has a version with the fix".

We could consider automoving on RC release rather than final release?

-- 
Lionel