Rick Hillegas (JIRA) wrote:
Assigning this bug to 10.2 and bumping its priority to Critical. This will make
it visible to bug-fixers. Once the Urgency field appears, we can adjust the
severity of this bug.
I think it is really important not to muck with the priority (mental
translation SEVERITY) settings even with the intention of setting them
back later on. A good way to cope until we have Urgency is to look
first at the open product regression list first:
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&component=11670&component=11406&component=12310670&component=12310194&component=11407&component=11409&component=11690&component=11410&component=11411&component=11415&component=11408&component=11412&component=11414&status=1&status=3&status=4&customfield_12310090=Regression&sorter/field=issuekey&sorter/order=DESC
and then at the Blocker/Critical issues.
But I really feel stronger each day that Priority needs to stay as
outlined in Jira and below:
Blocker
Blocks development and/or testing work, production could not run
Critical
Crashes, loss of data, severe memory leak.
Major
Major loss of function.
Minor
Minor loss of function, or other problem where easy workaround is
present.
Trivial
Cosmetic problem like misspelt words or misaligned text.
Andrew said that he would have this by the end of the week so we are
talking about a day's wait. We should not corrupt our bug database
with wrong data or our thinking with wrong mappings by setting it
incorrectly. I have made this mistake myself in not marking DERBY-700
Critical because it is hard to fix. That was very wrong thinking on my
part. I fear has caused users to lose their data. DERBY-700 is
Priority *Critical*. It's Urgency might be something else based on how
hard it is to fix.
Kathey
