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: Bug triage for 10.5.2
Date Wed, 22 Jul 2009 13:47:44 GMT
Kathey Marsden wrote:
> 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.
Hi Kathey,

It sounds like you want to use the Urgency field as a primary way to 
organize your bug-fixing efforts. For the record, I mostly ignore that 
field. Instead, I try to let the "facts" about the issues guide my 
bug-fixing. That is, my default ranking for bugs leads me to search for 
bugs in this order:

data corruptions
wrong results
crashes

This approach always pops DERBY-700 to the top, regardless of the 
release manager's judgment.

Regards,
-Rick
>
>
>> 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.
>
> Kathey
>


Mime
View raw message