Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Date: Wed, 22 Jul 2009 06:47:44 -0700
From: Rick Hillegas <Richard.Hillegas@Sun.COM>
Subject: Re: Bug triage for 10.5.2
In-reply-to: <4A663451.5070904@sbcglobal.net>
Sender: Richard.Hillegas@Sun.COM
To: derby-dev@db.apache.org
Message-id: <4A671880.2070904@sun.com>
References: <19020.59678.546770.272905@gargle.gargle.HOWL>
 <4A660085.4010801@sun.com> <4A66075B.3060500@sbcglobal.net>
 <4A6613AC.2050606@sun.com> <4A663451.5070904@sbcglobal.net>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)

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
>