You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <fl...@gmail.com> on 2007/01/02 23:02:29 UTC
[all] Jira reporting
Using the commons-nightly/jira-email.vm swizzle script, I've got a
report for the Commons projects that lets us see the status of things.
Here's the output:
http://people.apache.org/~bayard/jira-report-for-commons.txt
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 was pondering whether this would have value to be emailed to
commons-dev once a week?
Any thoughts?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [pipeline] Any working examples
Posted by Kris Nuttycombe <Kr...@noaa.gov>.
At present, the best publicly available working example can be found in
the unit test source code. Take a look at
org.apache.commons.pipeline.config.DigesterPipelineFactoryTest and the
associated file test_conf.xml in the test resources. I have received a
number of requests for better examples and will work to get a more
detailed, walkthrough-style example online in the next week or so.
Kris
Mark Proctor wrote:
> Are there any end to end working examples of commons pipeline?
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
=====================================================
Kris Nuttycombe
Associate Scientist II
Enterprise Data Systems
National Geophysical Data Center/NOAA
(303) 497-6337
Kris.Nuttycombe@noaa.gov
=====================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[pipeline] Any working examples
Posted by Mark Proctor <li...@markproctor.com>.
Are there any end to end working examples of commons pipeline?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Jira reporting
Posted by Martin van den Bemt <ml...@mvdb.net>.
That sounds nice, but than the vote needs to be on general :)
I would be an favor of that..
Mvgr,
Martin
Dennis Lundberg wrote:
>
> Why not move all JIRA notifications to issues@j.a.o ?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Jira reporting
Posted by Dennis Lundberg <de...@apache.org>.
Henri Yandell wrote:
> On 1/6/07, Henri Yandell <fl...@gmail.com> wrote:
>> On 1/6/07, Joerg Heinicke <jo...@gmx.de> wrote:
>> > Henri Yandell <flamefew <at> gmail.com> writes:
>> >
>> > > The spam issue is a tricky decision. Sometimes I turn off the
>> > > notifications to then do a lot of changes, other times I let the spam
>> > > hit the list because moving an issue into a version is a decision. If
>> > > there were a lot of them, I'd be tempted to send an email to the list
>> > > saying "Moving these issues into XXX" and then do a bulk move with
>> the
>> > > send-email option turned off.
>> > >
>> > > That'd be a nice JIRA feature - bulk-email notification rather than
>> > > individual notification for each issue.
>> >
>> > Another way to let it be less bugging would be a splitting of this
>> mailing list
>> > into multiple ones. No, not project specific - I know you love the
>> > cross-pollination :) But splitting it into
>> > commons-cvs|svn|scm@jakarta.apache.org (many projects have their own
>> list for
>> > commit mails), commons-jira|issues|bugs@jakarta.apache.org (don't
>> know a project
>> > having this, but would love to see this, especially because of the
>> topic we are
>> > actually talking about) and the actual dev list for discussions.
>> This would
>> > finally make it possible to read current heavy traffic lists like
>> geronimo-dev
>> > and this one on mailing list archives. At the moment I often get
>> lost in the
>> > huge amount of mails and I refrain from subscribing to both metioned
>> lists.
>> >
>> > WDYT? Any chance for implementation?
>>
>> We talked about this a while back, and though there was some
>> disagreement the consensus was definitely in favour of splitting the
>> 'noise' off onto another list. Making the archives more readable was
>> the big reason. It's just not been done.
>>
>> I think it's more common to move things over to the commits list than
>> making a list for each source. Maven currently does this.
>>
>> I can definitely do it for JIRA no problem, so then it's just a matter
>> of getting a wiki change. I'll let this sit for a few days to make
>> sure no-one -1s, and then go ahead and make it happen.
>
> Scratch that - I misremembered the solution - it was about different
> lists, not just moving JIRA and Wiki onto the -commits list. The svn
> commits still show in the -dev list. No plans to do anything on my
> part.
Why not move all JIRA notifications to issues@j.a.o ?
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Jira reporting
Posted by Henri Yandell <fl...@gmail.com>.
On 1/6/07, Henri Yandell <fl...@gmail.com> wrote:
> On 1/6/07, Joerg Heinicke <jo...@gmx.de> wrote:
> > Henri Yandell <flamefew <at> gmail.com> writes:
> >
> > > The spam issue is a tricky decision. Sometimes I turn off the
> > > notifications to then do a lot of changes, other times I let the spam
> > > hit the list because moving an issue into a version is a decision. If
> > > there were a lot of them, I'd be tempted to send an email to the list
> > > saying "Moving these issues into XXX" and then do a bulk move with the
> > > send-email option turned off.
> > >
> > > That'd be a nice JIRA feature - bulk-email notification rather than
> > > individual notification for each issue.
> >
> > Another way to let it be less bugging would be a splitting of this mailing list
> > into multiple ones. No, not project specific - I know you love the
> > cross-pollination :) But splitting it into
> > commons-cvs|svn|scm@jakarta.apache.org (many projects have their own list for
> > commit mails), commons-jira|issues|bugs@jakarta.apache.org (don't know a project
> > having this, but would love to see this, especially because of the topic we are
> > actually talking about) and the actual dev list for discussions. This would
> > finally make it possible to read current heavy traffic lists like geronimo-dev
> > and this one on mailing list archives. At the moment I often get lost in the
> > huge amount of mails and I refrain from subscribing to both metioned lists.
> >
> > WDYT? Any chance for implementation?
>
> We talked about this a while back, and though there was some
> disagreement the consensus was definitely in favour of splitting the
> 'noise' off onto another list. Making the archives more readable was
> the big reason. It's just not been done.
>
> I think it's more common to move things over to the commits list than
> making a list for each source. Maven currently does this.
>
> I can definitely do it for JIRA no problem, so then it's just a matter
> of getting a wiki change. I'll let this sit for a few days to make
> sure no-one -1s, and then go ahead and make it happen.
Scratch that - I misremembered the solution - it was about different
lists, not just moving JIRA and Wiki onto the -commits list. The svn
commits still show in the -dev list. No plans to do anything on my
part.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Jira reporting
Posted by Henri Yandell <fl...@gmail.com>.
On 1/6/07, Joerg Heinicke <jo...@gmx.de> wrote:
> Henri Yandell <flamefew <at> gmail.com> writes:
>
> > The spam issue is a tricky decision. Sometimes I turn off the
> > notifications to then do a lot of changes, other times I let the spam
> > hit the list because moving an issue into a version is a decision. If
> > there were a lot of them, I'd be tempted to send an email to the list
> > saying "Moving these issues into XXX" and then do a bulk move with the
> > send-email option turned off.
> >
> > That'd be a nice JIRA feature - bulk-email notification rather than
> > individual notification for each issue.
>
> Another way to let it be less bugging would be a splitting of this mailing list
> into multiple ones. No, not project specific - I know you love the
> cross-pollination :) But splitting it into
> commons-cvs|svn|scm@jakarta.apache.org (many projects have their own list for
> commit mails), commons-jira|issues|bugs@jakarta.apache.org (don't know a project
> having this, but would love to see this, especially because of the topic we are
> actually talking about) and the actual dev list for discussions. This would
> finally make it possible to read current heavy traffic lists like geronimo-dev
> and this one on mailing list archives. At the moment I often get lost in the
> huge amount of mails and I refrain from subscribing to both metioned lists.
>
> WDYT? Any chance for implementation?
We talked about this a while back, and though there was some
disagreement the consensus was definitely in favour of splitting the
'noise' off onto another list. Making the archives more readable was
the big reason. It's just not been done.
I think it's more common to move things over to the commits list than
making a list for each source. Maven currently does this.
I can definitely do it for JIRA no problem, so then it's just a matter
of getting a wiki change. I'll let this sit for a few days to make
sure no-one -1s, and then go ahead and make it happen.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Jira reporting
Posted by Niall Pemberton <ni...@gmail.com>.
On 1/7/07, Dennis Lundberg <de...@apache.org> wrote:
> Joerg Heinicke wrote:
> > Henri Yandell <flamefew <at> gmail.com> writes:
> >
> >> The spam issue is a tricky decision. Sometimes I turn off the
> >> notifications to then do a lot of changes, other times I let the spam
> >> hit the list because moving an issue into a version is a decision. If
> >> there were a lot of them, I'd be tempted to send an email to the list
> >> saying "Moving these issues into XXX" and then do a bulk move with the
> >> send-email option turned off.
> >>
> >> That'd be a nice JIRA feature - bulk-email notification rather than
> >> individual notification for each issue.
> >
> > Another way to let it be less bugging would be a splitting of this mailing list
> > into multiple ones. No, not project specific - I know you love the
> > cross-pollination :) But splitting it into
> > commons-cvs|svn|scm@jakarta.apache.org (many projects have their own list for
> > commit mails), commons-jira|issues|bugs@jakarta.apache.org (don't know a project
> > having this, but would love to see this, especially because of the topic we are
> > actually talking about) and the actual dev list for discussions. This would
> > finally make it possible to read current heavy traffic lists like geronimo-dev
> > and this one on mailing list archives. At the moment I often get lost in the
> > huge amount of mails and I refrain from subscribing to both metioned lists.
>
> Maven uses both commits@maven.a.o and issues@maven.a.o
As does Struts.
+1 for JIRA --> issues@ and wiki changes --> commits@
Niall
> > WDYT? Any chance for implementation?
>
> +1
>
> > Regards
> > Jörg
>
>
> --
> Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Jira reporting
Posted by Dennis Lundberg <de...@apache.org>.
Joerg Heinicke wrote:
> Henri Yandell <flamefew <at> gmail.com> writes:
>
>> The spam issue is a tricky decision. Sometimes I turn off the
>> notifications to then do a lot of changes, other times I let the spam
>> hit the list because moving an issue into a version is a decision. If
>> there were a lot of them, I'd be tempted to send an email to the list
>> saying "Moving these issues into XXX" and then do a bulk move with the
>> send-email option turned off.
>>
>> That'd be a nice JIRA feature - bulk-email notification rather than
>> individual notification for each issue.
>
> Another way to let it be less bugging would be a splitting of this mailing list
> into multiple ones. No, not project specific - I know you love the
> cross-pollination :) But splitting it into
> commons-cvs|svn|scm@jakarta.apache.org (many projects have their own list for
> commit mails), commons-jira|issues|bugs@jakarta.apache.org (don't know a project
> having this, but would love to see this, especially because of the topic we are
> actually talking about) and the actual dev list for discussions. This would
> finally make it possible to read current heavy traffic lists like geronimo-dev
> and this one on mailing list archives. At the moment I often get lost in the
> huge amount of mails and I refrain from subscribing to both metioned lists.
Maven uses both commits@maven.a.o and issues@maven.a.o
> WDYT? Any chance for implementation?
+1
> Regards
> Jörg
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
splitting commons-dev mailing list (was: [all] Jira reporting)
Posted by Joerg Heinicke <jo...@gmx.de>.
Joerg Heinicke <joerg.heinicke <at> gmx.de> writes:
> ... splitting it into commons-cvs|svn|scm <at> jakarta.apache.org,
> commons-jira|issues|bugs <at> jakarta.apache.org and the actual dev list for
> discussions ...
I just wanted to ping on this one [1]. There seems to be much agreement about
splitting the list [2]. So is there any progress?
Jörg
[1] http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=116813323403039&w=4
[2] http://marc.theaimsgroup.com/?t=116777554800001&r=1&w=4
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Jira reporting
Posted by Joerg Heinicke <jo...@gmx.de>.
Henri Yandell <flamefew <at> gmail.com> writes:
> The spam issue is a tricky decision. Sometimes I turn off the
> notifications to then do a lot of changes, other times I let the spam
> hit the list because moving an issue into a version is a decision. If
> there were a lot of them, I'd be tempted to send an email to the list
> saying "Moving these issues into XXX" and then do a bulk move with the
> send-email option turned off.
>
> That'd be a nice JIRA feature - bulk-email notification rather than
> individual notification for each issue.
Another way to let it be less bugging would be a splitting of this mailing list
into multiple ones. No, not project specific - I know you love the
cross-pollination :) But splitting it into
commons-cvs|svn|scm@jakarta.apache.org (many projects have their own list for
commit mails), commons-jira|issues|bugs@jakarta.apache.org (don't know a project
having this, but would love to see this, especially because of the topic we are
actually talking about) and the actual dev list for discussions. This would
finally make it possible to read current heavy traffic lists like geronimo-dev
and this one on mailing list archives. At the moment I often get lost in the
huge amount of mails and I refrain from subscribing to both metioned lists.
WDYT? Any chance for implementation?
Regards
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Jira reporting
Posted by Henri Yandell <fl...@gmail.com>.
On 1/5/07, Joerg Heinicke <jo...@gmx.de> wrote:
> Martin Cooper <martinc <at> apache.org> writes:
>
> > > > 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
> > issues.
>
> Ok, that's a point. Cocoon does indeed suffer from this as well. But I guess in
> Cocoon changing this would just not work (or end in 300 "issue version
> re-addressed" mails per release). For the maintenance branch the development is
> much less targeted as it is more or less only project-driven, i.e. an issues
> that a committer needs on his current project gets handled rapidly. Other issues
> are mostly done on demand or on request. For littler projects or projects with
> less chaotic project management (which I like much though :)) the above might
> indeed be useful.
Yeah, for a larger project it'd be more painful. I think you'd want to
be thinking about more defined process - this one is an intentionally
lightweight hack that seems to work with little buy in.
The spam issue is a tricky decision. Sometimes I turn off the
notifications to then do a lot of changes, other times I let the spam
hit the list because moving an issue into a version is a decision. If
there were a lot of them, I'd be tempted to send an email to the list
saying "Moving these issues into XXX" and then do a bulk move with the
send-email option turned off.
That'd be a nice JIRA feature - bulk-email notification rather than
individual notification for each issue.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Jira reporting
Posted by Joerg Heinicke <jo...@gmx.de>.
Martin Cooper <martinc <at> apache.org> writes:
> > > 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
> issues.
Ok, that's a point. Cocoon does indeed suffer from this as well. But I guess in
Cocoon changing this would just not work (or end in 300 "issue version
re-addressed" mails per release). For the maintenance branch the development is
much less targeted as it is more or less only project-driven, i.e. an issues
that a committer needs on his current project gets handled rapidly. Other issues
are mostly done on demand or on request. For littler projects or projects with
less chaotic project management (which I like much though :)) the above might
indeed be useful.
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Jira reporting
Posted by Martin Cooper <ma...@apache.org>.
On 1/3/07, Henri Yandell <fl...@gmail.com> wrote:
>
> On 1/3/07, Joerg Heinicke <jo...@gmx.de> 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.
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
issues.
--
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> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [all] Jira reporting
Posted by Henri Yandell <fl...@gmail.com>.
On 1/3/07, Joerg Heinicke <jo...@gmx.de> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Jira reporting
Posted by Joerg Heinicke <jo...@gmx.de>.
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.
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.
Regards
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Jira reporting
Posted by Dennis Lundberg <de...@apache.org>.
Henri Yandell wrote:
> On 1/2/07, Dennis Lundberg <de...@apache.org> wrote:
>> Henri Yandell wrote:
>> > Using the commons-nightly/jira-email.vm swizzle script, I've got a
>> > report for the Commons projects that lets us see the status of things.
>> > Here's the output:
>> >
>> > http://people.apache.org/~bayard/jira-report-for-commons.txt
>> >
>> > 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 was pondering whether this would have value to be emailed to
>> > commons-dev once a week?
>> >
>> > Any thoughts?
>> >
>> > Hen
>>
>> Nice!
>>
>> Just need some help with interpretation:
>>
>> Commons BeanUtils <----- Component (got that one)
>> 1.8.0 - 19 / 79
>> ^ ^ ^
>> | | |
>> ----+ | |
>> version | |
>> | |
>> ----------+ |
>> solved issues |
>> in that vers.? |
>> ---------------+
>> total scheduled issues for that version?
>
> Explaining it would have been a stunning idea :)
>
> You got it right. Version, resolved, total. Using resolved seemed more
> natural than unresolved. After that I leave it up to human
> interpretation - it's unlikely that "2/2" means that a release should
> happen, but "31/32" should mean it's time to release soon.
And any component with a high number of solved issues deserves a
release, no matter what the total says, say like 40/300.
> I'd like to include a bit of info in the 'Unresolved" list on the
> number of comments (and unique comment authors), but that's not
> currently implemented (either in Swizzle or JIRA not sure where it's
> missing), so I need to go figure out why not.
One thing that I have seen in reports like this one over in Maven land
is the number votes. This is meant to indicate the users wish as to what
issues to deal with first. See this one for the Maven plugins:
http://repo1.maven.org/reports/plugins/plugin-issues.txt
The numbers are:
- total number of votes to the left of the plugin name
- number of votes for the particular issue, to the left of each issue
This one is not sorted alphabetically, but by descending number of votes
per plugin.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Jira reporting
Posted by Henri Yandell <fl...@gmail.com>.
On 1/2/07, Dennis Lundberg <de...@apache.org> wrote:
> Henri Yandell wrote:
> > Using the commons-nightly/jira-email.vm swizzle script, I've got a
> > report for the Commons projects that lets us see the status of things.
> > Here's the output:
> >
> > http://people.apache.org/~bayard/jira-report-for-commons.txt
> >
> > 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 was pondering whether this would have value to be emailed to
> > commons-dev once a week?
> >
> > Any thoughts?
> >
> > Hen
>
> Nice!
>
> Just need some help with interpretation:
>
> Commons BeanUtils <----- Component (got that one)
> 1.8.0 - 19 / 79
> ^ ^ ^
> | | |
> ----+ | |
> version | |
> | |
> ----------+ |
> solved issues |
> in that vers.? |
> ---------------+
> total scheduled issues for that version?
Explaining it would have been a stunning idea :)
You got it right. Version, resolved, total. Using resolved seemed more
natural than unresolved. After that I leave it up to human
interpretation - it's unlikely that "2/2" means that a release should
happen, but "31/32" should mean it's time to release soon.
I'd like to include a bit of info in the 'Unresolved" list on the
number of comments (and unique comment authors), but that's not
currently implemented (either in Swizzle or JIRA not sure where it's
missing), so I need to go figure out why not.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Jira reporting
Posted by Dennis Lundberg <de...@apache.org>.
Henri Yandell wrote:
> Using the commons-nightly/jira-email.vm swizzle script, I've got a
> report for the Commons projects that lets us see the status of things.
> Here's the output:
>
> http://people.apache.org/~bayard/jira-report-for-commons.txt
>
> 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 was pondering whether this would have value to be emailed to
> commons-dev once a week?
>
> Any thoughts?
>
> Hen
Nice!
Just need some help with interpretation:
Commons BeanUtils <----- Component (got that one)
1.8.0 - 19 / 79
^ ^ ^
| | |
----+ | |
version | |
| |
----------+ |
solved issues |
in that vers.? |
---------------+
total scheduled issues for that version?
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org