db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Jira field definition clarification for Derby
Date Mon, 31 Jul 2006 13:59:41 GMT
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
>
>


Mime
View raw message