db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre" <mcintyr...@gmail.com>
Subject Re: Re: prioritized 10.2 bug list
Date Wed, 12 Jul 2006 23:23:23 GMT
On 7/12/06, Rick Hillegas <Richard.Hillegas@sun.com> 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

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


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


View raw message