Hi bfo,
I am sorry for the late replay. I had busy days.
On Mon, 2012-06-04 at 08:55 -0700, bfo wrote:
Petr Mladek wrote
Yes, any help is really appreciated. If you feel like, please propose
some prioritization.
From my users perspective the proposal is simple:
1. crashers
2. dataloss
3. regressions
4. something do not work as expected bugs
5. enhancements
Nice, it looks very reasonable! I like that it is easy. I am unable to
create such easy rules myself ;-)
Well, I slightly miss some more aspects:
+ how many people are affected
+ how the problem is visible
+ workaround exists and how it is complicated
+ how old the problem is (2-3 years old bugs might loose the
regression taste; people are getting used to the new
behavior; we should not have such regressions but
we sometimes end there because it is hard to debug and
the other aspects)
If I compare it with the rules for Novell bugzilla, I see the following
differences:
1. Novell rules put crashers and dataloss bugs on the same level
(critical). IMHO, it is reasonable. I guess that you would end there
as well ;-)
2. Novell rules do not stress the word "regression". They are more
influenced by the other aspects and try to split functional problems
into three categories (Major, Normal, Minor). I would like to have
this in our proposal as well.
IMHO, it does not make sense to spend time on regression that is hard
to reproduce and fix if there are more important problems that people
miss.
On the other hand, it makes sense to fix behavior of a new feature
that people like and start using heavily. It is not regression but
it annoys quite some people.
Also we need to somehow propose rules for the priorities flag.
Would you be interested into creating more precise proposal that would
incomporate the other aspects?
We need not make too complex rules. The severity and priority are just
helper items. Developers do not strictly follow the flags. Of course,
they concentrate more on the severe bugs. Though, when they debug or
rework some piece of code, they fix even less important bugs. It is more
effective when they have the code in the head.
BTW: With time scheduled release cycle (monthly in your case) IMHO it is
difficult to triage bugs as blockers or critical anyway.
I do not know if you are prepared to do chemspills, emergency releases or
stop the release channel if things go wrong big time...
Good point! I tried to get out of this trap by rules described at
https://wiki.documentfoundation.org/Release_Criteria#Blocker_Bug_Definition
Maybe, but changing to NEW is quite complicated
in your workflow, so mostly I leave them as UNCONFIRMED.
Heh, what is complicated about it? Is the documentation unclear? IMHO,
if you make sure that e bug is reproducible with the given information,
you could move it to the state NEW.
I thought so, but according to http://wiki.documentfoundation.org/BugTriage
there are three bold ANDs before you can change a status to NEW.
Further more, an exclamation mark at the end of that paragraph
(and the whole scary sentence before it) discouraged me to change anything
in the Status field at all.
I wonder if the new wording is better. In each case, we need to make it
friedly. We need more people doing the bug triage.
Best Regards,
Petr
Context
- Re: 3.5.3rc1 win32 / debug package ... (continued)
crasher bugs and most annoying bugs generated by automation [was: 3.5.3rc1 win32 / debug package ...] · Bjoern Michaelsen
Re: 3.5.3rc1 win32 / debug package ... · Petr Mladek
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.