db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Bug triage for 10.5.2
Date Tue, 21 Jul 2009 21:34:09 GMT
Rick Hillegas wrote:
>> 1) Make urgency specific to a release by also setting the fix version 
>> field for open bugs.
>> For issues marked Urgent or Blocker I think it would be good to also 
>> mark a fix version.  That way we could manage urgency for multiple 
>> releases and I think could safely get rid of High value fix.  I think 
>> in the past there was some objection to setting fix version on open 
>> issues, but it is still indicated I noticed in the release process [1].
> I'm not sure I understand what you're suggesting. I thought we had 
> agreed that the Urgency field was owned by the release manager.  Once 
> the bugs have been triaged, I'm happy to let successive release 
> managers express their individual judgments via the Urgency field. I 
> can see that there would be a conflict if two release managers were 
> putting out releases at the same time--but that's not a problem we 
> seem to have and I'd be happy to solve that problem when it actually 
> arises.
When I reviewed the urgency settings for bugs like DERBY-700,  I was 
concerned about throwing it back into the normal urgency bucket with 
1000 other issues.  It is clearly urgent from a community perspective 
but wasn't going to make it into this release.  My solution was to leave 
it Urgent even though it missed the release.  The next release manager 
can re-evaluate.

While I can see that some bugs like DERBY-4142 would be of greater 
concern to some members of the community than others.  I think that 
particularly for less platform specific issues there can be consensus on 
urgency.  I like to think of us as a single community, not two teams. 
There are in-fact always work for two releases at the same time.    I 
see value in marking release specific urgency.

> I see great value in tackling the untriaged issues regularly. Once a 
> month sounds good. I see less value in revisiting the already triaged 
> issues.  Some of the facts may change (for instance, "repro 
> available"), but many won't (e.g., a crash yesterday is still a crash 
> tomorrow). Which fields do you think need to be revisited every 
> release cycle?
Maybe even once a year would be ok for a full review.  The usual changes 
are for Assignee or resolution as Won't fix, Cannot reproduce or 
duplicate. Verification of the reproductions is also good. 

I guess the core problem is too many open bugs requiring lots of work to 
get a good view of what's most important.


View raw message