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


On 21/06/12 21:32, bfo wrote:

Petr Mladek wrote

I'd change the workflow a little bit by putting the obvious things at the
top:
- feature requests aka wishlist
I do not have any strong opinion for this. I think that it is is good to
be able to discuss features, so "enhancement" bugs in bugzilla might be
usable.
 - add target milestone if a feature is planned already
This must be done by developer, anyway :-)

Well, to be clear, I see all this more like how to triage guide, that is why
I started with enhancements.
Target milestone can be set by QA member if feature is available.
https://bugs.freedesktop.org/show_bug.cgi?id=33773#c11 for instance.

currently the target is set only after the bug is fixed, and this is how
it ought to work.  there general pattern is to add one "target:x.y.z"
value per branch where the fix is applied to the whiteboard.

in case you want the target to be set before the bug is fixed, as some
kind of planning mechanism, please be aware that this was actually done
in the OOo project, and that this worked so badly (i.e. the main result
was that every developer had some 100 bugs assigned to him that he moved
from target 3.0 to target 3.1 to target 3.2 etc. without ever having
time to fix them) that it was actually decided (shortly before the end)
to modify the process to set the target only after a bug is fixed, just
like it is in LO.

You are right, regression are bad and we need to fix them with high
priority. On the other hand, you still need to compare them with other
reported bugs and decide what is more annoying for the daily work. We
could not blindly set the highest priority for a tiny functional problem
just because it is a regression. As someone said, you could view almost
any bug as regression, so we need to prioritize them as well.
I would keep the current approach. Add "regression" into Whiteboard and
set one level higher priority that you would set for non-regression.

I disagree. Many people just won't upgrade because of them. Fast query shows
180 opened bugs with regression keyword. Very worrying...

agreed, regressions are generally more important than non-regressions,
precisely because they prevent users from using the latest version.

If someone change the priority a wrong way, I would ask them not to do
it, explain that the level is not that important, and change it back. If
they change it once again, I would leave it as is. Developers would
filter it themselves :-)

this developer has already learned to ignore bugzilla "priorities" :)

I think that it is not worth spending resources on migrating bugs to a
single bugzilla. IMHO, it is better to spend time on fixing other bugs,
improving the functionality, testing, ...

Already some bugs are migrated (from Symphony for instance). Some of them
are fixed already. 
I just can't imagine proper bug management in a project, when you have to
follow many bugtrackers.

this is a general problem of our project due to the convoluted history.

Disagree. It is a page for bug reporters. I really like the gerrit migration
and would like to see it integrated with Bugzilla. Also always precommit
hooks can be implemented if developers tend to forget to put a bug number
into a commit message. I already stumbled upon UNCONFIRMED bugs which have
been fixed already and suddenly changed into RESOLVED FIXED. I would like to
know what is going on with the bugs at any moment.

such a precommit hook doesn't work so well.  there are lots of commits
that do cleanups, refactorings, fix build breakers, etc. none of which
have or need a bug id.

in the OOo project there was a policy that every commit include a bug
id, and the result was that all of these build breaker fixes used the
same notorious #i10000# number, which doesn't help anybody.

i've sometimes found bugs that were already fixed on master, but in the
vast majority of the cases the author of the commit was not aware of the
bug, i.e. the bug was a almost-but-not-exactly duplicate of the bug the
author mentioned, or the author had a bug in a non-fdo tracker, or it
was just something the author found themselves or whatever.

Well, we do not want to create bug report for each fix. It is too
complex process with poor results. If a developer is talkative, she
provides a good commit message. If she is not talkative, she would
create useless bug report. We could motivate them by asking for details,
saying thanks for info, ...
Anyway, I think that it is not important now. We do not have enough
people who could test all commits, so we do not need perfect commit
messages.

It is very unfortunate and doesn't help triaging bugs. Another resource to
watch by QA member - the commits.
I really like Bugzilla developers strict workflow. Every commit with bug
number, patch reviewed by a specialist (not just +1 to get it as soon as
possible), bug assigned and status changed upon commit. It can be done
automatically.

we already have quite a bit of that, comments are added to bugzilla when
a commit mentions a bug, and with gerrit we'll soon handle reviews better.


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.