commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <>
Subject Re: [all] Jira reporting
Date Wed, 03 Jan 2007 17:20:57 GMT
On 1/3/07, Henri Yandell <> wrote:
> On 1/3/07, Joerg Heinicke <> wrote:
> > Henri Yandell <flamefew <at>> writes:
> >
> > > The aim is to provide us with information on where projects are
> > > release-wise and where we are in terms of answering new issues. Some
> > > of our components aren't there - for example Jelly which has 77
> > > unversioned issues and Attributes/Discovery which are ready to be
> > > retired. Some of the ones there should probably be removed for having
> > > too many unversioned issues.
> >
> > I wonder what's the problem with unversioned issues. It simply says "in
> the
> > future". Any exact targetting for unresolved issues will lead to "this
> issues
> > hasn't made it into the latest release, we try to get it into the next
> one"
> > mails polluting the mailing lists without nearly any additional value.
> I think that is a good thing as it means someone is looking at that
> issue each release and deciding that it won't go in that release. If
> it keeps getting punted all the time then someone can ask if it's ever
> going to happen.

This is exactly why we moved to something like what Hen is proposing for
Struts. We had oodles of issues just sitting there with no indication of
when, if ever, they were likely to be fixed, and no indication of whether
anyone was committed to looking at them. Once you start versioning the
issues, you get the beginnings of a roadmap rather than just a bucket of

Martin Cooper

Lang has a good example of an 'in the future'
> version. There's a "JDK 1.5 Release" version for a couple of issues
> that have constraints holding them back from going in any version
> soon.
> More importantly to the above - my comment that components with lots
> of unversioned issues need to be removed is not a slander against
> those components but a sign that they're not using the lightweight
> workflow I'm creating the report for:
> * unversioned = unaccepted
> * next version = being worked upon
> * post next version = later (though can usually be bumped to next
> version if it has a patch/unit test)
> * other versions = ....
> > Dennis Lundberg <dennisl <at>> writes:
> >
> > > And any component with a high number of solved issues deserves a
> > > release, no matter what the total says, say like 40/300.
> >
> > If it's just the number of resolved issues, you don't need the number of
> > unresolved issues assigned to a target release. I tend to agree with
> this POV.
> It can depend. I agree with Dennis' statement that a high number of
> resolved should be flagging a release (which is one of the reasons for
> the report), but if there were truly 300 issues planned for that
> release, then it's possible there was a reason. The first step after
> the release has been flagging is for someone to review the 260 and
> move them to another version - ie) to rethink the release plan.
> Seeing the 300 figure is pretty useful in that it tells us that a
> release plan is probably too much. BeanUtils has 79 issues in its
> 1.8.0. A bunch probably shouldn't go in 1.8.0, but when I went through
> the 100+ issues that were there those were the ones that I thought we
> should at least be looking at prior to the next release.
> Hen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message