Thanks, Kathey. This looks very good to me. I suspect there are also
some consistency rules which we'd like to enforce. It's possible that
some of these rules could be expressed as JIRA filters, which your wiki
page could link to. The filters would catch JIRAs which need a little
scrubbing.
Regards,
-Rick
Kathey Marsden wrote:
Recently there have been several discussions about the meaning of many
of the Jira fields.
Jira is a communication tool so I think it is very important that the
question asked by each field be exactly the same for each of us, even
though our own personal answers may indeed differ. I think we have
reached consensus on most. Here is the summary of my understanding of
the fields and what they mean:
Type: The type of issue. We use the Jira definitions:
https://issues.apache.org/jira/ShowConstantsHelp.jspa?decorator=popup#IssueTypes
Assignee - The assignee is the developer currently working on the
issue. Developers should unassign themselves when not actively
working on issues so that others can pick them up.
Component:: Sub-section(s) of the project relevant to the issue.
Derby also has two special Components (which I think should be
checkboxes) RegressionTestFailure - A derbyall or other regression
test failure. It may or may not be a product Bug.
Newcomer - A way to flag issues that might be good candidates for new
developers.
Affects Version - The earliest release where the issue is known to
exist as shown by sysinfo.
RESOLVE: What should this mean for non-bug issues?
Fix Version for Closed Issues -
The earliest release where the fix has been made and forward ported
to all higher rev maintenance branches and the trunk.
The assumption is that you can move to the latest of a higher rev
maintenance branch and get the fix. For example if the current
trunk version is 10.2 and the fix is in 10.0 , but not in 10.1, the
issue should just be resolved with Fix Version 10.2 and a comment
added for the special backport. Of course fixes that have not been
fixed in the trunk should not be marked resolved.
(Note: The current practice of marking multiple fix versions creates
problems with release notes and doesn't make sense because you should
really then mark fixin 10.3, 10.4 etc...)
Fix Version for Open Issues
For assigned issues, Fix Version is the release for which a
developer plans to fix the issue.
For unassigned issues, Fix version is marked if a fix is considered a
high value fix candidate for the release and could reasonably be
picked up and fixed in time for the release. See
http://wiki.apache.org/db-derby/HighValueFixCandidates for definition
of a high value fix candidate.
Priority - Priority in Jira means SEVERITY. We follow the Jira
definitions exactly for bugs.
https://issues.apache.org/jira/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels
RESOLVE: Current priorities do not map well to current priorities.
Urgency -
We currently use the Forrest definitions at:
http://forrest.apache.org/issues.html#urgency
Derby Special Info checkboxes:
Patch Available - Patch Available is checked when a contributor
would like a patch to be reviewed. It may be a complete patch ready
for commit or just a request for early feedback but comments should
indicate which. Developers should assign themselves to an issue when
marking patch available.
See http://wiki.apache.org/db-derby/PatchAdvice and
http://wiki.apache.org/db-derby/DerbyContributorChecklist.
Regression - The Bug is a Derby *product* regression. Some valid
operation using the Derby public interfaces that worked in a previous
version, works no more. Even once resolved the Regression checkbox
stays checked.
Existing Application Impact - This is an issue that may have a
negative impact on existing applications. Users should be able to
query issues with this box marked to determine what issues they
might face on upgrade. For example, most open regressions have
"Existing Application Impact." Once they are closed they no longer
do. Some intentional changes like DERBY-781 may impact existing
applications.
Release Note Needed - This is an issue that requires special
attention in the release notes.
If this looks like a good start at definitions I can put it on the
Wiki and then we can refine.
Thanks
Kathey
