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