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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
