Re: Cleaning bug list

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.