Re: Cleaning bug list

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.



> > - bugs reported against not supported branches - exclude those at
> > reporting
> > level by disabling old versions in select fields; but what to do when
> > they
> > appear anyway -  mark them as INVALID at triaging? ask the reporter to
> > check
> > in new version? Any comments?
> We need to be more careful here. The current rule is to do NOT modify
> the version picker if you reproduce the problem with newer version. It
> is because it is very valuable to know how the bug is old. It helps
> developers to locate it. So, maybe, we should do it the other way and
> set the field to the oldest version where it was found.
I was thinking about New bug reports, which should be reported for supported
branches only (proposed in
https://bugs.freedesktop.org/show_bug.cgi?id=51070). 
Unfortunately it depends on
https://bugs.freedesktop.org/show_bug.cgi?id=50198.



> > - is it Most Frequently Reported - then just dupe it 
> What do you mean by "Most Frequently Reported"?
Is it at https://bugs.freedesktop.org/duplicates.cgi for LibreOffice
product. Then it can be handled very quickly, 
but I see that searching for dupes is already listed on
http://wiki.documentfoundation.org/BugTriage



> I would personally enable voting as well but some other people thing
> that it is not objective.
Unfortunately I discovered
https://bugs.freedesktop.org/show_bug.cgi?id=39739. WONTFIXed by Mr
Bielefeld who authored
http://wiki.documentfoundation.org/Vote_for_Enhancement, where it begins
with "[...] Bugzilla bug tracking system does not support Votes for requests
as it is available for OpenOffice.org. Here you find an experimental Voting
(or better: statistical online survey), currently with only very few rules
and only for Enhancement requests." I am perplexed. How manual wiki voting,
adding special keywords to bugs can be better than automated, build-in, out
of the box, customizable voting within Bugzilla? Strange. 
I know that voting is not a recipe to find best bugs to fix/features to
implement, but I think that giving an ability to vote (even only for QA team
members or LO developers)  would help going forward. I do vote for features
in other Bugzillas myself. 



> 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...



> It actually helps to prioritize bugs as well. If reporter is not willing
> to provide more information, the problem is probably not that important
> for him.
Disagree, as providing proper bt is complicated. 



> Also note that some crashers are reproducible only in very strange
> circumstances. Also some scenarios are very hard to prepare. We just
> need help from reporters in these cases.

Sure, but IMHO only if bug is not reproducible.



> 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 :-)

 I found https://bugs.freedesktop.org/show_bug.cgi?id=49168. IMHO instead of
flooding the Bugzilla, one can just disable it. 



> 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.



> The ideal process is described at
> http://wiki.documentfoundation.org/BugReport_Details#Initial_state
> Of course, developers are just humans, sometimes quite overloaded and
> they do not follow the process. [...]
> developers to close bugs by asking about the state. I wonder, how often
> do you see such a bug with commits that is not closed?
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.



> 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 currently do not have enough people doing bug triage. If we have, we
> could start thinking about specializing. 
I thought people mentioned in
http://wiki.documentfoundation.org/FindTheExpert would be interested what is
going on in their component?



> I do not think that bugzilla is a good tool for handling these type of
> tasks ;-)
Disagree. I really like how Mozilla use Bugzilla (it's their tool, you
know). Every Action Item, problem, request etc. is in the bugtracker.
Everything. Since few weeks I try to know how LibreOffice project works and
I have big trouble with it. So many mailinglists, posts, wiki articles to
browse.   



> > Do you VERIFY bugs? I see just 62 bugs as VERIFIED FIXED. I do not see
> > such
> > section in Getting Involved. Surely there are users willing to
> > participate
> > this way.
> We do not have enough people to sort new bugs, so nobody took care of
> this :-)
> Would you like to create a wiki page describing the process? 
Why o why I expected such question....  :)



> What do you mean by the flag?
> MAB just works. [..]
> Alternatively, you just look at the query
> and you see list of still opened bugs.
> Note that the queries are available at
> http://wiki.documentfoundation.org/Release_Criteria#Blocker_Bug_Nomination
I can't describe it better than Bugzilla main developer, who offered help in
https://bugs.freedesktop.org/show_bug.cgi?id=33070.
Also https://bugs.freedesktop.org/docs/en/html/flags-overview.html is a good
read.
I really like how Mozilla projects are using flags to nominate blockers and
all other requests.
I can't imagine manageable and organized QA process without them. Please
consider...



> > Well, sorry for such a pack of off-topic questions, but I'd like to
> > understand QA in this project better.
> It is fine. I hope that I did not discourage you. I feel that you want
> to have everything perfect which is great. On the other hand, we have
> only limited resources, we are just humans, and we need to optimize the
> processes for this. The target is clear. We all want to improve LO with
> each release and have the best office suite ever :-)
> Thanks for all your contributions.
Not at all. As I am getting into this more and more the time has come to ask
- where I should sign to become QA member (level 1 :))?



> PS: If you reply, please try to configure your mail client, so it puts
> some prefix "> " before the old text and put your answer inline. 
I am sorry if I produce garbage, but due to various reasons I am using
nabble interface only...

Best regards.

--
View this message in context: 
http://nabble.documentfoundation.org/Cleaning-bug-list-tp3988836p3991648.html
Sent from the Dev mailing list archive at Nabble.com.