Agreed.

I think that we should outline a set of guidelines, but also realize that the priority is like beauty - it's in the eyes of the reporter.

I tend to troll through DRLVM JIRAs and do small things like comment or link, and one thing I'll add to my work is resetting priority based on how I see it, and defend it with a comment. Any other committer can do the same for DRLVM or any others, and if you disagree, change it and defend it.

The outcome won't be perfect, and we shouldn't spend too much time arguing about priority (if you you really think it's a major problem, fix it!), but I think that this would normalize the bug priirities over time...

geir

Mark Hindess wrote:
On 5 October 2006 at 20:05, "Mikhail Fursov" <[EMAIL PROTECTED]> wrote:
The priority of the bug could be the priority of the scenario this bug
affects.
So, we need to select some applications/scenarios and if one of these
applications failed - the bug is blocker or critical.

Major as default priority is OK (imo) because it's in the middle of the
list.

That logic only really works for me if the distribution of bugs by
priority is even.  So for example we'd have as many 'critical' bugs as
'trivial' ones.  I don't think (I hope!) that we do.

Most of our JIRA are classified as major.  Most of the bugs described in
the JIRA issues are actually minor or trivial.

I honestly think the classifications would better reflect reality if we
changed this.

Regards,
 Mark.

On 10/5/06, Anton Luht <[EMAIL PROTECTED]> wrote:
Hello, Salikh,

I just suggest rules to be written explicitly. Every bug submitter
tends to think that his bug or his application is the most important -
some limits should be put to avoid 90% of bugs being major and
critical.

On 10/5/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote:
Anton Luht wrote:
Hello,

Maybe it's worth to explicitly specify priorities for various kinds of
bugs? The advice that appears now near 'priority' drop-down in JIRA
list is general and not Harmony-specific. Bug submitters make decision
mostly by his/her intuition.

An example of rule set: VM hangs & crashes - critical, Junit tests
failures - major, application failures - major, exception
incompatibility - minor.
And what guidelines would you recommend for the corner cases,
when something is important for some people, and does not matter for
others?
For example, some people are trying to get Harmony to run x86_64 and
ia64 platforms,
while most of the project participants just do not care.


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
Regards,
Anton Luht,
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
Mikhail Fursov

------=_Part_20534_19790021.1160053532326--




---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to