Re: [Libreoffice] Bugzilla handling of multiple branches

Hi Lionel, all,

On Wed, 17 Aug 2011 20:49:43 +0200
Lionel Elie Mamane <lionel@mamane.lu>
wrote:

> Hi,
>
> I don't see any way in bugzilla to say things like:
>  bug present / not present in master / libreoffice-3.4, ...
>  bug fixed / not fixed in master / libreoffice-3.4, ...
>
> There is only *one* version field, and *one* status field, not one per
> branch.

The version field is the release the bug was found in, not a target and
thus never a branch. If the bug is known to be present in multiple
versions it should be the latest released version the bug is found
in. see also https://bugzilla.mozilla.org/page.cgi?id=fields.html

> So I don't know when to close a bug. When it is fixed in master? 
> When it is fixed in all branches where we want it fixed?

IMHO this is one of the areas where launchpad is a lot less confusung
than bugzilla as it has "Fix commited" and "Fix released" states, which
are easier to understand. But I still think the same logic should be
used in bugzilla:

 "RESOLVED" -> there is a fix commited on master and on the release
               branchs it was targeted too. By default a bug is
               _never_ targeted for a release branch.
 "CLOSED"   -> the fix has been released on the targeted versions. 

> For example, bug #40079; it is fixed in master, so I closed it. But
> now it shows up as not blocking "LibreOffice 3.4 most annoying bugs"
> anymore (it is striked out), which is incorrect since it is not fixed
> in 3.4.

IMHO, closing a bug where we have not yet released a fixed version is
wrong. Such a bug is RESOLVED, but never CLOSED. So when one does
the RESOLVED->CLOSED transition, one should comment which released
version has it fixed.

As for bugs that are fixed on master, but not on the release branch:
* per default, no bug has a release branch target
* if we decide a bug is important enough to be fixed on the release
  branch too, see the target as per Koheis mail, and REOPEN the bug for
  a round of backporting the fix to the release branch.

Best,

Bjoern


(*) Either because it never was a problem there, or because it was
fixed there. Having it fixed on master is always first priority as
everything else will lead to regressions. If something is only fixed on
master, but not a the release branch, it only means the issue will get
fixed later.

-- 
https://launchpad.net/~bjoern-michaelsen