Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Hi Lionel,

On Wed, Aug 17, 2011 at 2:49 PM, 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, ...

So, a rule of thumb I follow is, put the version number where the bug
will appear in the whiteboard section using

target:X.Y.Z (this needs to be one word to allow regexp search)

notation.  If the version where the fix appears is not clear, at least
mention to which branch the fix is pushed in the comment field *when*
marking the bug RESOLVED FIXED.  For instance, if the bug is fixed in
3.4.3, I would put target:3.4.3 in the whiteboard section.  if the bug
is fixed on master, I'd put target:3.5, or simply say "the fix is
pushed to master" in the comment.

There is only *one* version field, and *one* status field, not one per
branch.

IMO the version field should be the version where the bug is observed,
not the version that receives the fix.

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?

A bug should be marked fixed when the bug is pushed to at least one of
the branches in our repository.  It's normally the master branch, but
in case the bug is only relevant to the stable branch, then mark it
fixed when the bug is pushed to that branch.

If the fix is pushed to master only, but you think it's safe enough &
makes sense to the stable branch, then send a note to this list asking
for a review (with [REVIEW] in the subject line).

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.

In that case, take a look at the fix on master and see if the fix
looks trivial or safe.  If it is, then send a note to this list asking
for a review for a potential cherry-picking to the stable branch.  If
enough people agree, then we'll cherry-pick it to the stable branch.
If not, we won't.

Anyway, this is the normal steps that I follow.

HTH,

Kohei

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.