Hi Kathey,
I agree that this is a bit confusing. In other bug tracking systems
which I have used, there is a distinction between the priority and the
severity of a bug. Priority is the field which helps engineers figure
out which bug to tackle next. Severity captures the bug's impact on
customers. The concepts couple in one direction: High severity bugs
generally have high priority. However, the reverse is not necessarily
true: A bug could have high priority because it's low hanging fruit or
very important to a crucial customer, even though the bug does not
cripple the system or corrupt data. Unfortunately, JIRA seems to use one
field to track both facts together. I think that this is a defect in
JIRA. If someone knows how to add a severity field to our bug tracker,
that would be great.
For 10.2, I want to use the priority field to mean what it means in
other bug tracking systems: a field which helps engineers figure out
what to do next. I would appreciate it if people would use Blocker and
Critical to mean, respectively, "priority 1" and "priority 2".
Kathey Marsden wrote:
Rick Hillegas wrote:
Hi Kathey,
If an issue would cause you to vote -1 on the 10.2 release, please
mark the issue as Critical or Blocker.
I am looking now at the known open regressions and am still struggling
with how to set the priority. Here is the current list of 4.
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&resolution=-1&customfield_12310090=Regression&sorter/field=issuekey&sorter/order=DESC
My general feeling on regressions and the 10.2 release is that:
All known product regressions should be fixed for the release unless
we have a *very* strong case for introducing a regression into the
product. If the community agrees we should introduce the regression,
there should be a release note with the workaround documented.
I have a hard time mapping this to the Jira priorities which say:
Blocker
Blocks development and/or testing work, production could not run
Critical
Crashes, loss of data, severe memory leak.
How should I mark priority on these issues?
A couple of examples:
DERBY-765 : Valid query fails with ERROR X0A00: The select list
mentions column 'A' twice...
This is a regression that I think we sadly have to let in but don't
think we should release 10.2 until this has a comprehensive release
note and workaround documented.
I have added a release note to this issue.
DERBY-1554: IDENTITY_VAL_LOCAL() returned value is modified
incorrectly by a multi-row INSERT statement.
This is a regression from the fix for DERBY-353. This one I think
should definitely be fixed for 10.2
Please adjust this issue to priority 1 or 2, that is, Blocker or Critical.
Regards,
-Rick
