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 Tue, 21 Jul 2009 19:14:52 GMT
Hi Kathey,

Thanks for your additional comments. Some more thoughts inline...

Kathey Marsden wrote:
> Rick Hillegas wrote:
>> At this point, all of the chunks of bugs have been claimed.
> Thanks everyone who did this, especially Dag for coordinating and 
> those that took multiple chunks.  I think it was really good to have 
> it split up so that folks could take the time to try repros, attach 
> new ones etc.
>
> I think after going through the process and thinking about urgency 
> with relation to a release, I would propose the following changes to 
> the process for next time.
>
> 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.

I don't see much value in using this field to mean either of the following:

1) A commitment by a developer that they are going to deliver a fix in a 
particular release. I think that the "assigned to" field works well for 
that purpose already.

2) A subjective statement that a bug is important coupled with a request 
that someone else should fix the bug. I can see that this is useful to 
the two large teams of developers which are working on Derby--this would 
be a way to flag your teammates about what your manager thinks is 
important. But I see two problems with trying to encode this information 
on our JIRAs:

a) The two teams may have different priorities and can easily confuse 
one another or, worse, overwrite one another's judgments.

b) "Please scratch my itch" seems like an odd request to make in a 
scratch-your-own-itch community.
>
> 2) Set a regular schedule for this triage.  Once a month for new 
> issues (those with no urgency marked) and  a full pass again about 2 
> months before release.  Hopefully with more time the triage will have 
> more impact on bug fixing decisions.
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?

Thanks,
-Rick
>
> Kathey
>
> [1] http://wiki.apache.org/db-derby/DerbySnapshotOrRelease
>
>


Mime
View raw message