Re: Cleaning bug list

Joel Madero-2 wrote
> Version 2, changed orientation and tried to take comments into
> account. Let me know what you all think.
Hi.
This is a very nice workflow, but I have some questions:
- how you define "Bug prevent users from making professional quality work?"  
Interoperability issues are a big obstacle. If this package is supposed to
read/write MSOffice files, then every new bug in this area should have high
priority by default. I have reported two annoying:  
https://bugs.freedesktop.org/show_bug.cgi?id=47138 47138  and 
https://bugs.freedesktop.org/show_bug.cgi?id=49102 49102 . Are those
"prevent users from making professional quality work" enough? Home users can
live with a workaround, but it is impossible to expect that xx(x) users will
do it xx times a day. Everyday. That is not "professional" (even worse - it
is very "unprofessional" for those users migrated from MSO, where it just
worked).

I'd change the workflow a little bit by putting the obvious things at the
top:
- feature requests aka wishlist - add target milestone if a feature is
planned already
- 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?
- is it Most Frequently Reported - then just dupe it 
and now, if a bug is still there, triage it by the proposed workflow.

- how you define most and many - I reported those two bugs on behalf of ~xx
people - is my bug better than other reports? Should this be controlled by
number of dupes? At what levels? Maybe enabling voting feature of Bugzilla
would help here...

- regressions - this is a major problem and I think it deserves its own
place in the workflow. It is not a big problem for home users to switch the
version back and forth. But when we are talking in terms of bigger
deployment, when you have xx computers (and growing) it becomes a real
blocker sometimes. What good are new and fixed versions for, where there is
a regression which disqualifies the software for daily use? That is a big
problem.

- backtraces - not all people can do proper backtrace, especially on
Windows, so maybe while triaging crash bugs one could ask for one a QA
member? BTW: Having own dev build of LO 3.5.4.2 I can be QA contact for
missing bt for all Windows crash bugs (except Base) on that branch. 

- permissions - seems like every user has canconfirm (Can confirm a bug) and
editbugs (Can edit all aspects of any bug). Did you think about changing
that, so one could not interfere with QA actions or vandalize the bug
reports?

Bugs triaged.  But those are only b.f.o. bugs. Checking release info for
3.5.5.1 I can see such acronyms like bnc, i, rhbz and there are bugs
reported on b.f.o. coming from aoo (where they may be fixed already). Not
mentioning ubuntu, gentoo, opensuse and other bugtrackers. This is a very
serious problem, because not all bugs are in one place. Any comments about
that?

Does the developers have their workflow in Bugzilla? I compared few commits
(libreoffice/core libreoffice-3-5-5) with b.f.o reports:
- 50603 - not assigned, UNCONFIRMED>RESOLVED FIXED
- 43967 - assigned, UNCONFIRMED>NEW>RESOLVED
FIXED>REOPENED>ASSIGNED>RESOLVED FIXED
- 48601 - not assigned, UNCONFIRMED>NEW
- 50988 - assigned, UNCONFIRMED>ASSIGNED>RESOLVED FIXED
- 43249 - assigned, UNCONFIRMED>NEW>RESOLVED FIXED 

So, not bad but if there is more not assigned RESOLVED FIXED or NEW bugs
with commits in the repo, then I see a problem here. QA should know what is
happening with the bugs without the need to follow the comments. How does it
look for xxxx commits? Also I see a lot of commits without bug report number
in it. What is fixed then? I see it as another problem.

I see you do not use QA field in Bugzilla. Why is that? Every component of a
product can have its default QA specialist. Then developers responsible for
a component quality can get a notice of new bugs instead of news about all
of them. Also QA specialist assigned here could be responsible for
bibisecting, bt delivery or verifying the bug.

By the way - Browsing through dev/qa mailinglist I can see that you prefer
those lists than bugs in Bugzilla. For instance - are those action items
from ESC or QA meetings reported as bugs in Bugzilla? b.f.o is not used
project wide or am I missing something?

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.

I see you do not use flags and prefer Whiteboard. Why is that? Maybe a
better idea than a MAB nightmare (IMHO meta bugs with >300 comments are
useless) would be a release tracking flag, where QA would like to see a fix.
Mozilla projects use them a lot for instance...

Well, sorry for such a pack of off-topic questions, but I'd like to
understand QA in this project better.
Best regards.


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