splitting commons-dev mailing list (was: [all] Jira reporting)
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-devm=116813323403039w=4 [2] http://marc.theaimsgroup.com/?t=11677755481r=1w=4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
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 [EMAIL PROTECTED] ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
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|[EMAIL PROTECTED] (many projects have their own list for commit mails), commons-jira|issues|[EMAIL PROTECTED] (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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
On 1/6/07, Joerg Heinicke [EMAIL PROTECTED] 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|[EMAIL PROTECTED] (many projects have their own list for commit mails), commons-jira|issues|[EMAIL PROTECTED] (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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
On 1/6/07, Henri Yandell [EMAIL PROTECTED] wrote: On 1/6/07, Joerg Heinicke [EMAIL PROTECTED] 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|[EMAIL PROTECTED] (many projects have their own list for commit mails), commons-jira|issues|[EMAIL PROTECTED] (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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
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|[EMAIL PROTECTED] (many projects have their own list for commit mails), commons-jira|issues|[EMAIL PROTECTED] (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 [EMAIL PROTECTED] and [EMAIL PROTECTED] WDYT? Any chance for implementation? +1 Regards Jörg -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
On 1/7/07, Dennis Lundberg [EMAIL PROTECTED] 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|[EMAIL PROTECTED] (many projects have their own list for commit mails), commons-jira|issues|[EMAIL PROTECTED] (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 [EMAIL PROTECTED] and [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
Henri Yandell wrote: On 1/6/07, Henri Yandell [EMAIL PROTECTED] wrote: On 1/6/07, Joerg Heinicke [EMAIL PROTECTED] 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|[EMAIL PROTECTED] (many projects have their own list for commit mails), commons-jira|issues|[EMAIL PROTECTED] (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 [EMAIL PROTECTED] ? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
On 1/5/07, Joerg Heinicke [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
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]
Re: [all] Jira reporting
On 1/3/07, Henri Yandell [EMAIL PROTECTED] wrote: 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. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
On 1/2/07, Dennis Lundberg [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
Henri Yandell wrote: On 1/2/07, Dennis Lundberg [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]