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