On 7/12/06, Rick Hillegas <[EMAIL PROTECTED]> wrote:
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.
Or perhaps simply noticed something outside their area of expertise
that appears to be a must-fix before release issue.
2) The reporters used JIRA to record FIXME messages to themselves and
simply forgot to assign the bugs to themselves.
Certainly possible, I did that with a recent sysinfo issue and then
somebody else fixed it before I got back to it. So even if you forget
to assign yourself to it, doesn't mean someone else won't work on it!
:-)
3) Something else. What do you think it means?
Similar to 1, the copyright notice issue is an example of a mandate
from the ASF. We won't likely see many of these, but someone in the
community will have to address the issue before the community can
finish the release.
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?
Nice-to-haves. For example, there might be JIRAs issues for bugs with
functionality introduced in 10.2 that the person who introduced the
functionality filed but didn't assign themselves to. They might not be
showstoppers for the release, they may just need a release note or a
note in the docs.
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.
Well, in some sense you get to dictact what goes into the release as
release manager, since you should certainly feel free to bump an issue
out to a later release if it simply won't make the train in time and
it's not a showstopper quality issue. If someone just can't get their
'major' feature or bug fix in around the time you want this release
train to leave the station, it will just have to wait for the next. Of
course, you should always be sensitive to the community as well. If
somebody in the community upgrades an issue to blocker, pay attention
to what they have to say. If somebody files a new issue with blocker,
but really just needs a release note, don't be afraid to say it. It's
a balancing act, and these things tend to work themselves out in the
end.
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 you see a Major bug that seems like a must-fix for 10.2 that
currently has no target release, even if you don't plan on working on
it yourself, I would say mark it FixIn 10.2. I would say, since you're
the release manager, you can certainly punt any unassigned major bugs
out to a future release if they aren't showstoppers, and with
increasing zeal the closer you get to the release date.
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.
+1
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.
Isn't it fun? "Like herding cats" was one description I've heard. :-)
Kathey Marsden wrote:
> 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?
I don't agree with either of these. A person should be allowed to
assign themselves to a bug without specifying what release they are
working on. In the case of a complicated feature, e.g. the BOOLEAN
work, just because someone is working on it today does not mean they
know what release it will end up going into today.
And it's certainly possible that someone could identify an issue, like
the copyright rototill, that's a must-fix for 10.2 and specify that as
the target release without ever intending to do any work on it.
Of course, JIRA doesn't have a mechanism for enforcing these
constraints anyway, so there's no way to enforce either of these
things even if we wanted to. :-)
I think the bottom line is that if anyone browsing through JIRA sees
anything that looks incorrect in a JIRA issue, regardless of whether
its issue type, or target release, or whatever, that person should
feel empowered to correct it. If that new setting is incorrect, its
likely that someone on derby-dev will spot it when the JIRA mail goes
to the -dev list.
andrew
