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.
Kathey
