On 1/3/07, Joerg Heinicke <[EMAIL PROTECTED]> wrote:
Henri Yandell <flamefew <at> gmail.com> 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. 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> apache.org> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
