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
