Hi Kathey,

This is a good topic to discuss. Thank you for raising it. There are a lot of seemingly independent variables in a JIRA and I don't think that the community fills in these variables consistently. Maybe that's inevitable since we don't enforce any consistency rules when updating a JIRA. People have targetted bugs for fixing in 10.2 but haven't assigned the bugs to themselves. What does this mean? It could mean any of the following:

1) These bugs are stretch goals which the reporters hope someone will address before we cut the branch.

2) The reporters used JIRA to record FIXME messages to themselves and simply forgot to assign the bugs to themselves.

3) Something else. What do you think it means?

As you can see, I am confused too. My noodle is particularly baked by bugs which are

a) unassigned
b) targetted for 10.2
c) marked low priority

What does that mean?

I have been assuming that "Fix in 10.2" means that the community really wants the issue resolved before we cut the branch. I have tried to ensure that "Fix in 10.2" includes all Blocker and Critical issues. Beyond that, I have tried not to dictate which of the Major issues get rolled into 10.2. Should I? Instead, I have left this decision to the community's collective judgement.

As you can see, I'm unclear about how to handle unassigned low priority bugs targetted for 10.2. Do we really want these to trump untargetted Major bugs? If we get through all of our Major 10.2 issues, the community might want to make another pass through the untargetted Major bugs and promote some of them to 10.2 ahead of the cruft.

Please bear with me. This is my first attempt to manage a release and I welcome your advice about how to make the process more sensible.

Kathey Marsden wrote:

Rick Hillegas wrote:

Thanks to everyone for helping clean up JIRA and clarify the issues we want to address in 10.2. It would be great if we could march in priority order through the issues listed in the Open 10.2 Issues report at http://wiki.apache.org/db-derby/TenTwoRelease#head-7cf194b6c7305a0e83d0c9c422f0632215f6cb19.

Rick I don't understand this list. If I think a bug is a good candidate for 10.2, do I just mark it fix in 10.2 and leave it unassigned?
I had thought Fix In 10.2 just meant someone planned to fix it for 10.2


It sounds as though you would like a consistency checker which binds the concepts of Assignment and ReleaseTarget. A person should not be allowed to assign a bug without specifiying a target release. And vice-versa, a person should not be able to specify a target release without assigning the bug to someone--presumably themself. Do I understand you correctly?


Thanks for the clarification.

Kathey



Reply via email to