db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Jira field definition clarification for Derby
Date Sun, 30 Jul 2006 22:39:44 GMT
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:

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 

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.
RESOLVE: Current priorities do not map well to current priorities.

Urgency -
We currently use the Forrest definitions at:

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 

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.



View raw message