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: Derby handling of Jira's "Fix Version/s"- WAS Re: 10.3 wiki page question
Date Thu, 25 Jan 2007 15:37:58 GMT
Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>> Hi Mike,
>> I agree that the "Bug Fix Candidates" heading is misleading because 
>> the query sweeps up all open 10.3 issues, including bugs, features, 
>> and documentation. I agree that "Bug Fix Candidates" should have a 
>> more focussed query associated with it. Sounds like you're happy to 
>> wire a narrower one into that slot and that sounds fine to me. I 
>> think we should leave the original query hanging around, however. I 
>> expect it will be useful too.
> A simple solution would be to use the existing filter 'Derby open code 
> bugs'.
> I think the practice of marking bugs as fix in a specific release as a 
> way to encourage folks to address them is not working. For some users 
> it is misleading as they might believe that the bug *is* going to be 
> fixed in that release and thus are surprised when it is not. This does 
> not reflect well on the community. Another aspect is what happens when 
> the release is made without the bug being fixed, currently the bug 
> just gets marked as some future release which seems to be even further 
> from reality in terms of the chances of the bug being fixed in newly 
> selected release.
> As a concrete example the default front page for Derby on Jira says 
> has 62 open issues "due to be fixed", but all but a handful 
> are unassigned. The unassigned ones are not "due to be fixed" since 
> no-one is working on them. For the assigned ones I think maybe one is 
> actually suitable for Thus the reality, at the moment, is 
> that has one fix "due to be fixed" instead of 62.
> Jira already has two mechanisms to indicate a bug is important:
>   Priority (which is really a severity from the descriptions of Major, 
> Minor etc.)
>   Votes: anyone can vote for a bug, if you think something should be 
> fixed but don't have time to fix it, vote for it.
And there's another JIRA mechanism: the Urgency field. Probably we 
should consider anything that's high priority, highly urgent, or heavy 
with votes.
> Could we switch to the standard Jira mechanisms for indicating a bug 
> is important and reserve "Fix Version/s" to reflect the assignee's 
> expectations of where (which codelines) & when the issue will be 
> addressed?
I think this is a good idea. The release managers will appreciate not 
having to bulk-sweep untouched issues into the next bucket.
> Dan.
>> Thanks,
>> -Rick
>> Mike Matrigali wrote:
>>> The 10.3 page: 
>>> http://wiki.apache.org/db-derby/DerbyTenThreeRelease?highlight=%28TenThree%29

>>> has a heading: 10.3 Bug Fix Candidates
>>> but the query seems to include more than just bugs.  Was that the 
>>> intent, or should the query be changed.  It also seems to include 
>>> documentation fixes which look like they were meant to be tracked 
>>> separately in the next section.  I would find it interesting to
>>> track intended 10.3 bug fixes vs. features separately.  I can of
>>> course create my own queries, but just wanted ask first the intent
>>> of the existing query.
>>> And to 10.3 bug fix planning, anyone have any ideas how to best do 
>>> this.
>>> We have a set of bugs that we thought important enough to mark 
>>> 10.2.2 at
>>> one point and then they sort of got shifted to 10.2.3 and 10.2.4 (or 
>>> something like that - not sure).  Is it time to shift them to 10.3?
>>> I took a quick look at just the 10.3 bug candidates and cleaned up a 
>>> little - if I got it wrong, please feel free to update.

View raw message