Hi,
I think Kohei has covered most of the questions below but..
On 17/08/11 19:49, Lionel Elie Mamane wrote:
Hi,
[...]
So I don't know when to close a bug. When it is fixed in master?
yes, and normally the committer does that, is it a rule? I don't know,
it's just what I and at least I know others do. Normally I put the
commit id(s) and branches in the comment too. This time you closed the
bug before I got around to doing that and that kinda distracted me from
doing what I normally do
When
it is fixed in all branches where we want it fixed?
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),
when we want a bug to be fixed in the 3.4 release then we need to get
the patch into the general dev branch associated with 3.4 ( e.g. the
libreoffice-3-4 branch ) and also the release branch e.g.
libreoffice-3-4-3. There are rules though about committing to these
branches. Currently you need the approval of 1 reviewer to commit to the
libreoffice-3-4 branch and the approval of 3 reviewers to commit to the
release branch. I have already pushed the patch to 3.4 and//I already
asked for a review so that this bug can go into libreoffice-3-4-3. It is
a good idea to monitor the mailing list and the information that the
patch was pushed to master, 3.4 and request for approval to commit to
libreoffice-3-4-3 is all under that same thread you started about the
patch for that issue.
Noel
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.