Re: [all] Jira Groups and Roles
Niall Pemberton wrote: On 4/5/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Username: [EMAIL PROTECTED] ah, so not the dennislundberg one. :) I was a bit confused at that one not being a jakarta developer. While you're in there, you should delete your doppelganger and assign its reported issue over to your real user. How do you do that - I also have an old id. As JIRA admin you find it in the user browser and select delete. I got a warning when I did that saying This user cannot be deleted at this time because there are issues assigned to them, they have reported issues, or they are currently the lead of a project Yea, that happened for me too. I dived into the general JIRA settings and found that nobody was allowed to change the reporter of an issue. I have changed this now so that jira-administrators can do it. Here's what I did to get rid of my old user: Filter all issues reported by old user Bulk change - transition - reopen (for all closed issues) Bulk change - edit - set reporter to new user Bulk change - transition - close Delete old user One thing to keep in mind though, when you reopen an issue the resolution gets reset. So you need to remember the resolution for each issue :-( I'll investigate further. Do you want me to move all issues from [EMAIL PROTECTED] to niallp for you? Niall I suggest hassling Dennis to do it :) Hen -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira Groups and Roles
On 4/5/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Niall Pemberton wrote: On 4/5/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Username: [EMAIL PROTECTED] ah, so not the dennislundberg one. :) I was a bit confused at that one not being a jakarta developer. While you're in there, you should delete your doppelganger and assign its reported issue over to your real user. How do you do that - I also have an old id. As JIRA admin you find it in the user browser and select delete. I got a warning when I did that saying This user cannot be deleted at this time because there are issues assigned to them, they have reported issues, or they are currently the lead of a project Yea, that happened for me too. I dived into the general JIRA settings and found that nobody was allowed to change the reporter of an issue. I have changed this now so that jira-administrators can do it. Here's what I did to get rid of my old user: Filter all issues reported by old user Bulk change - transition - reopen (for all closed issues) Bulk change - edit - set reporter to new user Bulk change - transition - close Delete old user One thing to keep in mind though, when you reopen an issue the resolution gets reset. So you need to remember the resolution for each issue :-( I'll investigate further. Do you want me to move all issues from [EMAIL PROTECTED] to niallp for you? Yes please, that would be great if you could. Niall Niall I suggest hassling Dennis to do it :) Hen -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira Groups and Roles
Niall Pemberton wrote: On 4/5/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Niall Pemberton wrote: On 4/5/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Username: [EMAIL PROTECTED] ah, so not the dennislundberg one. :) I was a bit confused at that one not being a jakarta developer. While you're in there, you should delete your doppelganger and assign its reported issue over to your real user. How do you do that - I also have an old id. As JIRA admin you find it in the user browser and select delete. I got a warning when I did that saying This user cannot be deleted at this time because there are issues assigned to them, they have reported issues, or they are currently the lead of a project Yea, that happened for me too. I dived into the general JIRA settings and found that nobody was allowed to change the reporter of an issue. I have changed this now so that jira-administrators can do it. Here's what I did to get rid of my old user: Filter all issues reported by old user Bulk change - transition - reopen (for all closed issues) Bulk change - edit - set reporter to new user Bulk change - transition - close Delete old user One thing to keep in mind though, when you reopen an issue the resolution gets reset. So you need to remember the resolution for each issue :-( I'll investigate further. Do you want me to move all issues from [EMAIL PROTECTED] to niallp for you? Yes please, that would be great if you could. Niall Done, I also removed your old account. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira Groups and Roles
On 4/5/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Niall Pemberton wrote: On 4/5/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Niall Pemberton wrote: On 4/5/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Username: [EMAIL PROTECTED] ah, so not the dennislundberg one. :) I was a bit confused at that one not being a jakarta developer. While you're in there, you should delete your doppelganger and assign its reported issue over to your real user. How do you do that - I also have an old id. As JIRA admin you find it in the user browser and select delete. I got a warning when I did that saying This user cannot be deleted at this time because there are issues assigned to them, they have reported issues, or they are currently the lead of a project Yea, that happened for me too. I dived into the general JIRA settings and found that nobody was allowed to change the reporter of an issue. I have changed this now so that jira-administrators can do it. Here's what I did to get rid of my old user: Filter all issues reported by old user Bulk change - transition - reopen (for all closed issues) Bulk change - edit - set reporter to new user Bulk change - transition - close Delete old user One thing to keep in mind though, when you reopen an issue the resolution gets reset. So you need to remember the resolution for each issue :-( I'll investigate further. Do you want me to move all issues from [EMAIL PROTECTED] to niallp for you? Yes please, that would be great if you could. Niall Done, I also removed your old account. Thanks Dennis :-) Niall -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] Jira Groups and Roles
Can anyone say what the usual practice is for assigning groups/roles for people once they become a committer? Theres a Jakarta Developer group - it gets you committer role for Commons Lang and JCI but strangely nothing else. Would be simpler if it was documented somewhere. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira Groups and Roles
On 4/4/07, Niall Pemberton [EMAIL PROTECTED] wrote: Can anyone say what the usual practice is for assigning groups/roles for people once they become a committer? Theres a Jakarta Developer group - it gets you committer role for Commons Lang and JCI but strangely nothing else. Would be simpler if it was documented somewhere. Yeah, it's a bit of a mess. The new JIRA release added the concept of project roles - which is great for many Apache projects. However we want to be able to grant project roles to N JIRA projects at the same time and it doesn't help with that. So we need to stay on the old system of assigning a group to the project, rather than messing around with roles too much (though the roles stuff does allow for permission to be granted in the short term while a request for being added to the group is made). Jeff did a bulk reconfiguration of JIRA and it was only afterwards that I understood sufficiently that it won't help us much. So now we need to go ahead and add the jakarta-developers group to each project role administrator bit. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira Groups and Roles
On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Niall Pemberton [EMAIL PROTECTED] wrote: Can anyone say what the usual practice is for assigning groups/roles for people once they become a committer? Theres a Jakarta Developer group - it gets you committer role for Commons Lang and JCI but strangely nothing else. Would be simpler if it was documented somewhere. Yeah, it's a bit of a mess. The new JIRA release added the concept of project roles - which is great for many Apache projects. However we want to be able to grant project roles to N JIRA projects at the same time and it doesn't help with that. So we need to stay on the old system of assigning a group to the project, rather than messing around with roles too much (though the roles stuff does allow for permission to be granted in the short term while a request for being added to the group is made). Jeff did a bulk reconfiguration of JIRA and it was only afterwards that I understood sufficiently that it won't help us much. So now we need to go ahead and add the jakarta-developers group to each project role administrator bit. *pondering* Might be eaier to setup a Jakarta Permission that sets the group as having read/write by default, instead of using the Standard Permission and doing lots of configuring. That should be doable I think. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira Groups and Roles
On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Niall Pemberton [EMAIL PROTECTED] wrote: Can anyone say what the usual practice is for assigning groups/roles for people once they become a committer? Theres a Jakarta Developer group - it gets you committer role for Commons Lang and JCI but strangely nothing else. Would be simpler if it was documented somewhere. Yeah, it's a bit of a mess. The new JIRA release added the concept of project roles - which is great for many Apache projects. However we want to be able to grant project roles to N JIRA projects at the same time and it doesn't help with that. So we need to stay on the old system of assigning a group to the project, rather than messing around with roles too much (though the roles stuff does allow for permission to be granted in the short term while a request for being added to the group is made). Jeff did a bulk reconfiguration of JIRA and it was only afterwards that I understood sufficiently that it won't help us much. So now we need to go ahead and add the jakarta-developers group to each project role administrator bit. *pondering* Might be eaier to setup a Jakarta Permission that sets the group as having read/write by default, instead of using the Standard Permission and doing lots of configuring. That should be doable I think. I bow to your greater (and my lack of) Jira knowledge - but seeing that Jakarta Devs causes someone to automatically get JCI and LANG commiter role - shouldn't we just have two groups that do the same for all Commons. I was thinking something like Commons Committer group -- commiter role on all components Jakarta PMC -- pmc role on all jakarta sub-projects Niall Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira Groups and Roles
On 4/4/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Niall Pemberton [EMAIL PROTECTED] wrote: Can anyone say what the usual practice is for assigning groups/roles for people once they become a committer? Theres a Jakarta Developer group - it gets you committer role for Commons Lang and JCI but strangely nothing else. Would be simpler if it was documented somewhere. Yeah, it's a bit of a mess. The new JIRA release added the concept of project roles - which is great for many Apache projects. However we want to be able to grant project roles to N JIRA projects at the same time and it doesn't help with that. So we need to stay on the old system of assigning a group to the project, rather than messing around with roles too much (though the roles stuff does allow for permission to be granted in the short term while a request for being added to the group is made). Jeff did a bulk reconfiguration of JIRA and it was only afterwards that I understood sufficiently that it won't help us much. So now we need to go ahead and add the jakarta-developers group to each project role administrator bit. *pondering* Might be eaier to setup a Jakarta Permission that sets the group as having read/write by default, instead of using the Standard Permission and doing lots of configuring. That should be doable I think. I bow to your greater (and my lack of) Jira knowledge - but seeing that Jakarta Devs causes someone to automatically get JCI and LANG commiter role - shouldn't we just have two groups that do the same for all Commons. I was thinking something like Commons Committer group -- commiter role on all components Jakarta PMC -- pmc role on all jakarta sub-projects Or one group *nod* (as I ended up dumping the idea of PMC and committers being different in JIRA). Sorry - I over-JIRA'd my reply above I suspect in trying to say the same thing. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira Groups and Roles
Niall Pemberton wrote: On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Niall Pemberton [EMAIL PROTECTED] wrote: Can anyone say what the usual practice is for assigning groups/roles for people once they become a committer? Theres a Jakarta Developer group - it gets you committer role for Commons Lang and JCI but strangely nothing else. Would be simpler if it was documented somewhere. Yeah, it's a bit of a mess. The new JIRA release added the concept of project roles - which is great for many Apache projects. However we want to be able to grant project roles to N JIRA projects at the same time and it doesn't help with that. So we need to stay on the old system of assigning a group to the project, rather than messing around with roles too much (though the roles stuff does allow for permission to be granted in the short term while a request for being added to the group is made). Jeff did a bulk reconfiguration of JIRA and it was only afterwards that I understood sufficiently that it won't help us much. So now we need to go ahead and add the jakarta-developers group to each project role administrator bit. *pondering* Might be eaier to setup a Jakarta Permission that sets the group as having read/write by default, instead of using the Standard Permission and doing lots of configuring. That should be doable I think. I bow to your greater (and my lack of) Jira knowledge - but seeing that Jakarta Devs causes someone to automatically get JCI and LANG commiter role - shouldn't we just have two groups that do the same for all Commons. I was thinking something like Commons Committer group -- commiter role on all components Jakarta PMC -- pmc role on all jakarta sub-projects This sound good to me. Then as Henri said, we should set up a new Permission Scheme. We now have a JIRA installation at my day job, so I have taken some time to experiment with groups and permissions. If you feel comfortable with me being a JIRA admin here, I could try to set this up. Niall Hen -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira Groups and Roles
On 4/4/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Niall Pemberton wrote: On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Niall Pemberton [EMAIL PROTECTED] wrote: Can anyone say what the usual practice is for assigning groups/roles for people once they become a committer? Theres a Jakarta Developer group - it gets you committer role for Commons Lang and JCI but strangely nothing else. Would be simpler if it was documented somewhere. Yeah, it's a bit of a mess. The new JIRA release added the concept of project roles - which is great for many Apache projects. However we want to be able to grant project roles to N JIRA projects at the same time and it doesn't help with that. So we need to stay on the old system of assigning a group to the project, rather than messing around with roles too much (though the roles stuff does allow for permission to be granted in the short term while a request for being added to the group is made). Jeff did a bulk reconfiguration of JIRA and it was only afterwards that I understood sufficiently that it won't help us much. So now we need to go ahead and add the jakarta-developers group to each project role administrator bit. *pondering* Might be eaier to setup a Jakarta Permission that sets the group as having read/write by default, instead of using the Standard Permission and doing lots of configuring. That should be doable I think. I bow to your greater (and my lack of) Jira knowledge - but seeing that Jakarta Devs causes someone to automatically get JCI and LANG commiter role - shouldn't we just have two groups that do the same for all Commons. I was thinking something like Commons Committer group -- commiter role on all components Jakarta PMC -- pmc role on all jakarta sub-projects This sound good to me. Then as Henri said, we should set up a new Permission Scheme. We now have a JIRA installation at my day job, so I have taken some time to experiment with groups and permissions. If you feel comfortable with me being a JIRA admin here, I could try to set this up. Far me comfortable with you doing it than me - thats for sure ;-) Niall Niall Hen -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira Groups and Roles
On 4/4/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Niall Pemberton wrote: Commons Committer group -- commiter role on all components Jakarta PMC -- pmc role on all jakarta sub-projects This sound good to me. Then as Henri said, we should set up a new Permission Scheme. We now have a JIRA installation at my day job, so I have taken some time to experiment with groups and permissions. If you feel comfortable with me being a JIRA admin here, I could try to set this up. Sure. What's your login? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira Groups and Roles
Henri Yandell wrote: On 4/4/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Niall Pemberton wrote: Commons Committer group -- commiter role on all components Jakarta PMC -- pmc role on all jakarta sub-projects This sound good to me. Then as Henri said, we should set up a new Permission Scheme. We now have a JIRA installation at my day job, so I have taken some time to experiment with groups and permissions. If you feel comfortable with me being a JIRA admin here, I could try to set this up. Sure. What's your login? Hen Username: [EMAIL PROTECTED] Full Name: Dennis Lundberg -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira Groups and Roles
On 4/4/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Username: [EMAIL PROTECTED] ah, so not the dennislundberg one. :) I was a bit confused at that one not being a jakarta developer. While you're in there, you should delete your doppelganger and assign its reported issue over to your real user. JIRA Admin done btw. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira Groups and Roles
On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Username: [EMAIL PROTECTED] ah, so not the dennislundberg one. :) I was a bit confused at that one not being a jakarta developer. While you're in there, you should delete your doppelganger and assign its reported issue over to your real user. How do you do that - I also have an old id. Niall JIRA Admin done btw. Hen
Re: [all] Jira Groups and Roles
On 4/4/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Username: [EMAIL PROTECTED] ah, so not the dennislundberg one. :) I was a bit confused at that one not being a jakarta developer. While you're in there, you should delete your doppelganger and assign its reported issue over to your real user. How do you do that - I also have an old id. As JIRA admin you find it in the user browser and select delete. I suggest hassling Dennis to do it :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira Groups and Roles
On 4/5/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Username: [EMAIL PROTECTED] ah, so not the dennislundberg one. :) I was a bit confused at that one not being a jakarta developer. While you're in there, you should delete your doppelganger and assign its reported issue over to your real user. How do you do that - I also have an old id. As JIRA admin you find it in the user browser and select delete. I got a warning when I did that saying This user cannot be deleted at this time because there are issues assigned to them, they have reported issues, or they are currently the lead of a project Niall I suggest hassling Dennis to do it :) Hen
[all] jira report
Thought I'd mention this again. It's cron'd nightly: http://people.apache.org/~bayard/jira-report-for-commons.txt I often randomly click through the JIRA projects - and it was much nicer to run down the report and look at each project. The above was made for an email, but I'll probably go ahead and html it up so the links are clickable etc. Interesting things that it implies to me (with a dumb set of mental rules): Configuration 1.4 is ready for a release (surprise!) FileUpload 1.2 is ready (shock!) DBCP 1.2.2 is ready for a release (you're stunned) CLI 1.1 seems close to a release (no one cares) JXPath 1.3 is nearly ready (?) Net 2.0 is ready (?) Chain 1.3 might be ready for a release Logging 1.1.1 might be ready for a release (we all know it is) Pool 2.0 might be ready for a release (probably not I presume) Net 1.5 might be ready for release Fixing versions on the Nightly Build seems odd (Digester has 1, Pool has 4, VFS has 3). You can't later tell what version they went in. If it was a fix for something like the website and didn't go in a version, I'd either use the next version or have it have no fix version. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
[all] JIRA issue types
FYI, I updated the issue type scheme of all commons projects today to the Apache default. This means that we now don't get the Infrastructure and Geronimo issue types in commons when creating an issue. No action is required by commoners as a result of this change. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] JIRA issue types
Thanks. I hadn't noticed that they were different :) Hen On 7/20/06, Stephen Colebourne [EMAIL PROTECTED] wrote: FYI, I updated the issue type scheme of all commons projects today to the Apache default. This means that we now don't get the Infrastructure and Geronimo issue types in commons when creating an issue. No action is required by commoners as a result of this change. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] JIRA straightening out
As you've noticed, IO is now pretty much in a 'everything has a fix version' state. The only exception are Finder issues, which I'd like to move to the sandbox, and a general issue that I should probably move from IO over to SITE (deploying javadoc/source for Commons jars). When modifying versions on resolved/closed issues I turn off the notifications, but when I start making version decisions on the open issues I turn them back on again. So my happy jira list is now IO, Lang, Modeler, Attributes and CLI. Modeler, Attributes and Lang all look close to release. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira id naming convention for Jakarta projects; WAS Re: [all] Jira?
On Fri, 2006-04-28 at 23:58 +0200, Dennis Lundberg wrote: Henri Yandell wrote: On 4/28/06, Dennis Lundberg [EMAIL PROTECTED] wrote: I think that having a naming scheme is a good idea. From a user standpoint I see no reason for keeping the project ids short (3-4 characters). If Jakarta will be sharing the Jira instance with other ASF projects then using a J prefix for Jakarta project should be used, like this: - JLANG - JDIGESTER - JCOLLECTIONS - JHTTPCORE It does seem to be that there's more interest in the full name than the shorter one. In terms of the J***, we should we be asking infra@ what they want to do. If infra don't require us to use a prefix then we shouldn't use one. Keep it as simple as possible, but still readable. Folks, Then I will go ahead and try to scrap the existing project and create a new one with JHTTPCORE as the project id. Please complain loudly if you have any objections to that. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira id naming convention for Jakarta projects; WAS Re: [all] Jira?
On 4/29/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Fri, 2006-04-28 at 23:58 +0200, Dennis Lundberg wrote: Henri Yandell wrote: In terms of the J***, we should we be asking infra@ what they want to do. If infra don't require us to use a prefix then we shouldn't use one. Keep it as simple as possible, but still readable. Folks, Then I will go ahead and try to scrap the existing project and create a new one with JHTTPCORE as the project id. Please complain loudly if you have any objections to that. Let me find out if Infra are worried about clash with prefix or not. If not, then it'll be HTTPCORE. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jira id naming convention for Jakarta projects; WAS Re: [all] Jira?
Henri Yandell wrote: On 4/27/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Henri Yandell wrote: Given this positive feedback so far, I'm going to email the infra@ mailing list to see how they would go about doing it _if_ we decided we wanted to move. I think we should be moving from 1 project with 37 components to 37 projects - it'll allow us to manage the components individually of each other without the kind of version overlap and general noise issues that we currently have. Jakarta Http Components just created their first Jira, and they got the name JHCHTTPCORE. Thus this _could_ get caught up in a debate about Jakarta and groupings. That's the id-code rather than the name (afaik). I didn't know that that was being standardised - JHCHTTPCORE is terrible, sounds like a sneeze. Ideally we should use whatever we want, it's not a namespace to fight over, just need to be unique. Henri, I also find JHCHTTPCORE absolutely horrible. I chose this id as I thought it would be the most politically correct one. I would very much rather prefer HTTPCORE or JHTTPCORE. Do you envisage a particular Jira id naming convention for Jakarta projects? At this point it is still not too late for us to scrap the project and start over with a different (better) project id. Oleg Personally, I'd like to see each component able to move grouping within Jakarta, thus we should use naming like JAKLANG or JAKARTALANG, rather than JLCLANG (for Jakarta Language Components). We also need to be aware that about half the commons websites now have links tailored to bugzilla, and these links get placed into maven built distributed projects. Another bit of work to do. Not sure anything can be done about that one. Do you mean the sites that get stuck in the zips (by maven built distributed projects) or something else? I suspect that every project has had a period of cold turkey when it moved over. Any idea Martin? Is there a .htaccess in the Bugzilla somehow? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
Big +1 on a move to jira.. Mvgr, Martin Henri Yandell wrote: I know Jelly are on Jira already, and Struts have just moved over to Jira. Wondering what the view is nowadays on Commons moving to Jira? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira id naming convention for Jakarta projects; WAS Re: [all] Jira?
On 4/28/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote: I also find JHCHTTPCORE absolutely horrible. I chose this id as I thought it would be the most politically correct one. I would very much rather prefer HTTPCORE or JHTTPCORE. Do you envisage a particular Jira id naming convention for Jakarta projects? At this point it is still not too late for us to scrap the project and start over with a different (better) project id. I don't think it's important to have a scheme - it's just a project id that is used in such a way that users are aware of it. HCO, HTCO, JHTC. Doesn't matter and I agree with the Atlassian advice on it being a 3 or 4 letter code. So: LANG IO COLL CODX (though tempting to go with 5 letters when it fits, CODEC etc) ATTR BEAN etc. Dunno if that matches with the infra@ view. Having something with 11 letters is a pain in the arse given that the only time I ever find myself using the id is: a) to discuss something outside of Jira and b) to enter into the find box in the top right. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira id naming convention for Jakarta projects; WAS Re: [all] Jira?
On 4/28/06, Henri Yandell [EMAIL PROTECTED] wrote: I don't think it's important to have a scheme - it's just a project id that is used in such a way that users are aware of it. HCO, HTCO, JHTC. Doesn't matter and I agree with the Atlassian advice on it being a 3 or 4 letter code. So: LANG IO COLL CODX (though tempting to go with 5 letters when it fits, CODEC etc) ATTR BEAN etc. Dunno if that matches with the infra@ view. Having something with 11 letters is a pain in the arse given that the only time I ever find myself using the id is: a) to discuss something outside of Jira and b) to enter into the find box in the top right. I rarely if at all use the project names so for me at least their size wouldn't matter. Besides, given the amount of projects at Jakarta, a limitation of 3 or 4 makes it very hard to define meaningful names. Not to mention that something like IO or LANG is quite generic - if there would be projects that provide similar functionality in Perl or C# then we would run into trouble (IO2, LANG2 ?). At least they could be prefixed like this: JAK_LANG JAK_IO JAK_COLL JAK_CODEC JAK_ATTR JAK_BEAN etc., or something similar. cheers, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira id naming convention for Jakarta projects; WAS Re: [all] Jira?
On 4/28/06, Henri Yandell [EMAIL PROTECTED] wrote: On 4/28/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote: I also find JHCHTTPCORE absolutely horrible. I chose this id as I thought it would be the most politically correct one. I would very much rather prefer HTTPCORE or JHTTPCORE. Do you envisage a particular Jira id naming convention for Jakarta projects? At this point it is still not too late for us to scrap the project and start over with a different (better) project id. I don't think it's important to have a scheme - it's just a project id that is used in such a way that users are aware of it. HCO, HTCO, JHTC. Doesn't matter and I agree with the Atlassian advice on it being a 3 or 4 letter code. So: LANG IO COLL CODX (though tempting to go with 5 letters when it fits, CODEC etc) ATTR BEAN etc. Dunno if that matches with the infra@ view. Having something with 11 letters is a pain in the arse given that the only time I ever find myself using the id is: a) to discuss something outside of Jira and b) to enter into the find box in the top right. ...and commit messages - since jira can link to commits if you put the issue number in the commit message. My preference would be something more relevant rather than 3/4 characters (e.g. I prefer BEANUTILS to BEAN) - also what about filtering for the jira messages sent to the list - again wouldn't e.g. BEANUTILS be better? Struts recently moved to jira - apparently this can't be changed once its set - so it needs to be right from the start. Niall Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira id naming convention for Jakarta projects; WAS Re: [all] Jira?
On Apr 28, 2006, at 10:29 AM, Henri Yandell wrote: Dunno if that matches with the infra@ view. Having something with 11 letters is a pain in the arse given that the only time I ever find myself using the id is: a) to discuss something outside of Jira and b) to enter into the find box in the top right. You also have the ability to link svn commits to Jira tickets by entering the ticket id in the commit message. Another reason for going with short, but memorable id's. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira id naming convention for Jakarta projects; WAS Re: [all] Jira?
Oleg Kalnichevski wrote: Henri Yandell wrote: On 4/27/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Henri Yandell wrote: Given this positive feedback so far, I'm going to email the infra@ mailing list to see how they would go about doing it _if_ we decided we wanted to move. I think we should be moving from 1 project with 37 components to 37 projects - it'll allow us to manage the components individually of each other without the kind of version overlap and general noise issues that we currently have. Jakarta Http Components just created their first Jira, and they got the name JHCHTTPCORE. Thus this _could_ get caught up in a debate about Jakarta and groupings. That's the id-code rather than the name (afaik). I didn't know that that was being standardised - JHCHTTPCORE is terrible, sounds like a sneeze. Ideally we should use whatever we want, it's not a namespace to fight over, just need to be unique. Henri, I also find JHCHTTPCORE absolutely horrible. I chose this id as I thought it would be the most politically correct one. I would very much rather prefer HTTPCORE or JHTTPCORE. Do you envisage a particular Jira id naming convention for Jakarta projects? At this point it is still not too late for us to scrap the project and start over with a different (better) project id. It would be a good idea to look at what the Maven community has done with Jira. They have used Jira for some time now. They have their Jira over at Codehaus and share the Jira instance with other projects: http://jira.codehaus.org/secure/BrowseProjects.jspa They have a naming scheme that prefixes all Maven 2 plugins with M. This is followed by the plugins name. They don't use fancy acronyms which are hard to read or remember. Some examples: - MANT - MJAVADOC - MCHECKSTYLE I think that having a naming scheme is a good idea. From a user standpoint I see no reason for keeping the project ids short (3-4 characters). If Jakarta will be sharing the Jira instance with other ASF projects then using a J prefix for Jakarta project should be used, like this: - JLANG - JDIGESTER - JCOLLECTIONS - JHTTPCORE If we can have our own Jira instance for Jakarta then the prefix can easily be dropped. I'm not subscribes to infra@ so I don't follow the discussions there. As mentioned elsewhere the project id will show up in the issue-emails that are sent to the dev-list. Having meaningful ids there helps human filtering as well as automatic mail filters. snip -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira id naming convention for Jakarta projects; WAS Re: [all] Jira?
On 4/28/06, Dennis Lundberg [EMAIL PROTECTED] wrote: I think that having a naming scheme is a good idea. From a user standpoint I see no reason for keeping the project ids short (3-4 characters). If Jakarta will be sharing the Jira instance with other ASF projects then using a J prefix for Jakarta project should be used, like this: - JLANG - JDIGESTER - JCOLLECTIONS - JHTTPCORE It does seem to be that there's more interest in the full name than the shorter one. In terms of the J***, we should we be asking infra@ what they want to do. I don't think we should be embracing the J*** bit out of future-worry if they're not concerned. I can agree that a more readable code makes for more readable email subjects (the name is in the body of the jira email not the subject, so hard to filter on that); but the prefixing with J issue then makes it unreadable and doesn't seem necessary. If we can have our own Jira instance for Jakarta then the prefix can easily be dropped. I'm not subscribes to infra@ so I don't follow the discussions there. Talked to Jeff about this. It won't be its own instance. Aim is to keep things in the one instance. The current extra instances are temporary until they can be sucked into the main one. In terms of ids, obviously one for each project. Do we also want one for Commons in general for build and site issues? And I presume we'd have a sandbox project. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira id naming convention for Jakarta projects; WAS Re: [all] Jira?
On 4/28/06, Henri Yandell [EMAIL PROTECTED] wrote: snip/ It does seem to be that there's more interest in the full name than the shorter one. snap/ I don't think we should imply a x character limit either. Hopefully, everyone will choose the shortest name that still makes sense. In terms of the J***, we should we be asking infra@ what they want to do. I don't think we should be embracing the J*** bit out of future-worry if they're not concerned. I can agree that a more readable code makes for more readable email subjects (the name is in the body of the jira email not the subject, so hard to filter on that); but the prefixing with J issue then makes it unreadable and doesn't seem necessary. snip/ Agreed, lets not have prefixes please. In terms of ids, obviously one for each project. Do we also want one for Commons in general for build and site issues? snip/ Yes. And I presume we'd have a sandbox project. snap/ Yes. Also, are we talking about migrating Commons or Jakarta to JIRA? Finally, take my comments for what they're worth since unfortunately, I have no cycles to contribute towards this move. -Rahul Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira id naming convention for Jakarta projects; WAS Re: [all] Jira?
Henri Yandell wrote: On 4/28/06, Dennis Lundberg [EMAIL PROTECTED] wrote: I think that having a naming scheme is a good idea. From a user standpoint I see no reason for keeping the project ids short (3-4 characters). If Jakarta will be sharing the Jira instance with other ASF projects then using a J prefix for Jakarta project should be used, like this: - JLANG - JDIGESTER - JCOLLECTIONS - JHTTPCORE It does seem to be that there's more interest in the full name than the shorter one. In terms of the J***, we should we be asking infra@ what they want to do. If infra don't require us to use a prefix then we shouldn't use one. Keep it as simple as possible, but still readable. snip/ In terms of ids, obviously one for each project. Do we also want one for Commons in general for build and site issues? And I presume we'd have a sandbox project. How about COMMONS for general commons stuff? And perhaps JAKARTA as well. We could either use SANDBOX for all sandbox components or create one id for each sandbox component. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Carman wrote: I'm +1. JIRA is much more user friendly and intuitive, IMHO. I like JIRA too. I have reported a lot of bugs for other OS projects using JIRA, cause it's intuitive. As i saw the commons bugzilla instance first time i was really afraid. Meanwhile i have learned how to find what i want, but i can't say i really like this ugly thing. For this religious things: there is a free license and commons could benefit from a switch (and if only if guys like me report more bugs ;-)). If they sell it expensive for enterprises- ok, i have sold commons components too (as part of my applications). As long as they do not decide to roll back this free license i don't care. Chris. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEUNHGkv8rKBUE/T4RAksKAJwPY74q4zGxefRKcQjukjtP5rvJLgCePt+C OKuk6YWBe2tPgb3R64Brd4I= =bow8 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
I use to be +0 in regards to Jira migration, but I've read some convincing arguments, so I'm now firmly +1 in favour. I think the roadmap feature is almost worth migrating for alone. Rory Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Carman wrote: I'm +1. JIRA is much more user friendly and intuitive, IMHO. I like JIRA too. I have reported a lot of bugs for other OS projects using JIRA, cause it's intuitive. As i saw the commons bugzilla instance first time i was really afraid. Meanwhile i have learned how to find what i want, but i can't say i really like this ugly thing. For this religious things: there is a free license and commons could benefit from a switch (and if only if guys like me report more bugs ;-)). If they sell it expensive for enterprises- ok, i have sold commons components too (as part of my applications). As long as they do not decide to roll back this free license i don't care. Chris. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEUNHGkv8rKBUE/T4RAksKAJwPY74q4zGxefRKcQjukjtP5rvJLgCePt+C OKuk6YWBe2tPgb3R64Brd4I= =bow8 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
I use to be +0 in regards to Jira migration, but I've read some convincing arguments, so I'm now firmly +1 in favour. I think the roadmap feature is almost worth migrating for alone. Rory Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Carman wrote: I'm +1. JIRA is much more user friendly and intuitive, IMHO. I like JIRA too. I have reported a lot of bugs for other OS projects using JIRA, cause it's intuitive. As i saw the commons bugzilla instance first time i was really afraid. Meanwhile i have learned how to find what i want, but i can't say i really like this ugly thing. For this religious things: there is a free license and commons could benefit from a switch (and if only if guys like me report more bugs ;-)). If they sell it expensive for enterprises- ok, i have sold commons components too (as part of my applications). As long as they do not decide to roll back this free license i don't care. Chris. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEUNHGkv8rKBUE/T4RAksKAJwPY74q4zGxefRKcQjukjtP5rvJLgCePt+C OKuk6YWBe2tPgb3R64Brd4I= =bow8 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
On 4/25/06, Henri Yandell [EMAIL PROTECTED] wrote: I know Jelly are on Jira already, and Struts have just moved over to Jira. Wondering what the view is nowadays on Commons moving to Jira? Except for Mario's -1, things seem to be +1 so far which I must admit is a bit of a surprise :) Given this positive feedback so far, I'm going to email the infra@ mailing list to see how they would go about doing it _if_ we decided we wanted to move. I think we should be moving from 1 project with 37 components to 37 projects - it'll allow us to manage the components individually of each other without the kind of version overlap and general noise issues that we currently have. We have 3,000 issues, which isn't a big deal I think, but we'd be wanting to add 37 new projects (and scoping to 100 let's say) which might be a concern, and the migration would need to be customised to map components to projects. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
Henri Yandell wrote: On 4/25/06, Henri Yandell [EMAIL PROTECTED] wrote: I know Jelly are on Jira already, and Struts have just moved over to Jira. Wondering what the view is nowadays on Commons moving to Jira? Except for Mario's -1, things seem to be +1 so far which I must admit is a bit of a surprise :) Given this positive feedback so far, I'm going to email the infra@ mailing list to see how they would go about doing it _if_ we decided we wanted to move. I think we should be moving from 1 project with 37 components to 37 projects - it'll allow us to manage the components individually of each other without the kind of version overlap and general noise issues that we currently have. +1 for that. We have 3,000 issues, which isn't a big deal I think, but we'd be wanting to add 37 new projects (and scoping to 100 let's say) which might be a concern, and the migration would need to be customised to map components to projects. Maven uses a *lot* of projects in Jira - one for each plugin (~50 for Maven 2) plus a bunch more for the core. That makes things manageable on the project (=commons component) level. Sometimes issues are moved between different plugins (=projects), so that is possible even if we use different projects for commons. Checking with infra seems like a good idea to get a well thought through strategy for the migration. Hen -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
Henri Yandell wrote: Given this positive feedback so far, I'm going to email the infra@ mailing list to see how they would go about doing it _if_ we decided we wanted to move. I think we should be moving from 1 project with 37 components to 37 projects - it'll allow us to manage the components individually of each other without the kind of version overlap and general noise issues that we currently have. Jakarta Http Components just created their first Jira, and they got the name JHCHTTPCORE. Thus this _could_ get caught up in a debate about Jakarta and groupings. Personally, I'd like to see each component able to move grouping within Jakarta, thus we should use naming like JAKLANG or JAKARTALANG, rather than JLCLANG (for Jakarta Language Components). We also need to be aware that about half the commons websites now have links tailored to bugzilla, and these links get placed into maven built distributed projects. Another bit of work to do. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
On 4/27/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Henri Yandell wrote: Given this positive feedback so far, I'm going to email the infra@ mailing list to see how they would go about doing it _if_ we decided we wanted to move. I think we should be moving from 1 project with 37 components to 37 projects - it'll allow us to manage the components individually of each other without the kind of version overlap and general noise issues that we currently have. Jakarta Http Components just created their first Jira, and they got the name JHCHTTPCORE. Thus this _could_ get caught up in a debate about Jakarta and groupings. Personally, I'd like to see each component able to move grouping within Jakarta, thus we should use naming like JAKLANG or JAKARTALANG, rather than JLCLANG (for Jakarta Language Components). Another option, now that infra is open, at least to some extent, to multiple JIRA instances (Struts has its own, for example), is to create a separate instance for Jakarta. Then you could just have LANG, and forget about prefixes altogether. -- Martin Cooper We also need to be aware that about half the commons websites now have links tailored to bugzilla, and these links get placed into maven built distributed projects. Another bit of work to do. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
On 4/27/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Henri Yandell wrote: Given this positive feedback so far, I'm going to email the infra@ mailing list to see how they would go about doing it _if_ we decided we wanted to move. I think we should be moving from 1 project with 37 components to 37 projects - it'll allow us to manage the components individually of each other without the kind of version overlap and general noise issues that we currently have. Jakarta Http Components just created their first Jira, and they got the name JHCHTTPCORE. Thus this _could_ get caught up in a debate about Jakarta and groupings. That's the id-code rather than the name (afaik). I didn't know that that was being standardised - JHCHTTPCORE is terrible, sounds like a sneeze. Ideally we should use whatever we want, it's not a namespace to fight over, just need to be unique. Personally, I'd like to see each component able to move grouping within Jakarta, thus we should use naming like JAKLANG or JAKARTALANG, rather than JLCLANG (for Jakarta Language Components). We also need to be aware that about half the commons websites now have links tailored to bugzilla, and these links get placed into maven built distributed projects. Another bit of work to do. Not sure anything can be done about that one. Do you mean the sites that get stuck in the zips (by maven built distributed projects) or something else? I suspect that every project has had a period of cold turkey when it moved over. Any idea Martin? Is there a .htaccess in the Bugzilla somehow? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
On 4/27/06, Henri Yandell [EMAIL PROTECTED] wrote: On 4/27/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Henri Yandell wrote: Given this positive feedback so far, I'm going to email the infra@ mailing list to see how they would go about doing it _if_ we decided we wanted to move. I think we should be moving from 1 project with 37 components to 37 projects - it'll allow us to manage the components individually of each other without the kind of version overlap and general noise issues that we currently have. Jakarta Http Components just created their first Jira, and they got the name JHCHTTPCORE. Thus this _could_ get caught up in a debate about Jakarta and groupings. That's the id-code rather than the name (afaik). I didn't know that that was being standardised - JHCHTTPCORE is terrible, sounds like a sneeze. Ideally we should use whatever we want, it's not a namespace to fight over, just need to be unique. Personally, I'd like to see each component able to move grouping within Jakarta, thus we should use naming like JAKLANG or JAKARTALANG, rather than JLCLANG (for Jakarta Language Components). We also need to be aware that about half the commons websites now have links tailored to bugzilla, and these links get placed into maven built distributed projects. Another bit of work to do. Not sure anything can be done about that one. Do you mean the sites that get stuck in the zips (by maven built distributed projects) or something else? I suspect that every project has had a period of cold turkey when it moved over. Any idea Martin? Is there a .htaccess in the Bugzilla somehow? Not directly. There was some discussion on this on infra@ a while ago. ISTR that someone (Jean Anderson, I think) was going to write something, but I've kinda lost track of whether anything actually happened. -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
Hi! I know Jelly are on Jira already, and Struts have just moved over to Jira. Wondering what the view is nowadays on Commons moving to Jira? I am -1 on moving to jira. I dont understand why we - the open source developers and our users - should help testing a commercial application. And given that even for a mid-size company the minimum required license is the professional one - and its update policy - it is a rather expensive thing. Also I dont understand whats the great benefit for us - compared to bugzilla - that we act as a marketing plattform for jira. Sorry if I completely missed the point. Do not hesitate to correct me. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all] Jira?
Hi all, -Original Message- From: Mario Ivankovits [mailto:[EMAIL PROTECTED] Sent: Wednesday, 26 April 2006 4:16 PM To: Jakarta Commons Developers List Subject: Re: [all] Jira? Hi! I am -1 on moving to jira. I dont understand why we - the open source developers and our users - should help testing a commercial application. And given that even for a mid-size company the minimum required license is the professional one - and its update policy - it is a rather expensive thing. Also I dont understand whats the great benefit for us - compared to bugzilla - that we act as a marketing plattform for jira. Sorry if I completely missed the point. Do not hesitate to correct me. Ciao, Mario Although my vote is non-binding, I am also opposed to the move. Unless the case for a switch is compelling and there are significant demonstrable benefits, why ditch Bugzilla? What doesn't it do that Jira does so well? Thanks, James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
-1 as well for the same reasons. JIRA is a nice product, but Bugzilla is quite good and fits our needs. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
Guys, it's not as if jira isn't installed already ;) So the buuuh! it's comercial is a bit too late IMO. I am pretty much +1 ...but not religious about it ...and I hope that everyone who voted -1 has actually tried to use jira before blocking things for the wrong reasons. Btw: we had pretty much the same discussion on cocoon-dev and switched. Maybe worth looking at other teams to see how the are doing with it? http://issues.apache.org/jira/browse/COCOON My 2 cents cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
Hi! Guys, it's not as if jira isn't installed already ;) So the buuuh! it's comercial is a bit too late IMO. And they conquered all of gaul really all no a small village resist ... ;-) ...and I hope that everyone who voted -1 has actually tried to use jira before blocking things for the wrong reasons. Yes, the myfaces development team use it - and so do I. I cant say that there is a single function I use from jira which is not available in bugzilla. Sure, such functions exists, but I do not need them. And no - I dont think these are the wrong reasons If the tool (jira) will be less expensive I'll change my vote to +1. I dont think they share their benefit (testing, marketing, etc) with the rest. e.g. For those using Intellij IDEA it is much more a boost in productivity and cost much less. Same for their update price. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
And they conquered all of gaul really all no a small village resist ... ;-) Hehe ;) ...and I hope that everyone who voted -1 has actually tried to use jira before blocking things for the wrong reasons. Yes, the myfaces development team use it - and so do I. I cant say that there is a single function I use from jira which is not available in bugzilla. Sure, such functions exists, but I do not need them. And no - I dont think these are the wrong reasons If the tool (jira) will be less expensive I'll change my vote to +1. I dont think they share their benefit (testing, marketing, etc) with the rest. e.g. For those using Intellij IDEA it is much more a boost in productivity and cost much less. Same for their update price. Well, your call ...sounds more like a -0 too me though. IMO we should concentrate on functionality first - not the political statement because jira already *is* being used by the ASF. Who cares if commons is not. I am not saying the political discussion is bogus but should probabaly discussed at a different level. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
I believe that one of the justifications for installing JIRA in the first place was that maintaining and upgrading Bugzilla was a big hassle for the infrastructure team. If that's the case, I'd be willing to consider moving; the infrastructure team have a hard job to do without us making it harder. But otherwise I'm perfectly happy with Bugzilla, and given that it's Free while Jira is not, that tilts me towards staying with bugzilla. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all] Jira?
I'm +1. JIRA is much more user friendly and intuitive, IMHO. I thought that the licensing was free for truly open-source projects. Maybe that's for more individual type open-source projects, though. Doesn't ASF qualify for one of their Non-Profit Open Source Licenses? -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 26, 2006 12:46 AM To: Jakarta Commons Developers List Subject: [all] Jira? I know Jelly are on Jira already, and Struts have just moved over to Jira. Wondering what the view is nowadays on Commons moving to Jira? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: RE: [all] Jira?
it looks to me like the asf already licenses/uses jira? http://issues.apache.org/jira/ so it should only a question about how to customize the behaviour of the working instance? regards engel
Re: [all] Jira?
On 4/25/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I know Jelly are on Jira already, and Struts have just moved over to Jira. Wondering what the view is nowadays on Commons moving to Jira? I am -1 on moving to jira. Reason for mentioning Struts above was that I remembered that one of the -ve votes a few years ago on moving to Jira was from Martin and I thought some other Struts guys; thus the email to see if the consensus had moved. I'm +1 in favour of Jira, but not religious about it. I dont understand why we - the open source developers and our users - should help testing a commercial application. This is a common reason to not use Jira. From an ASF point of view, it's a bit weak I think. The ASF encourages companies to build commercial products on top of open-source software so using things like Jira is kind-of using our own dog-food. If Atlassin just offered Apache a licence, then it would be the kind of thing that we wouldnt accept. However if they offer it to everyone, then it's much the same kind of thing we push for at the JCP - open-source projects shouldn't be locked out due to lack of money. Also I dont understand whats the great benefit for us - compared to bugzilla - that we act as a marketing plattform for jira. Major advantages of Jira: * Project based administration - rather than central administration. * Visualization is much better - release management really shouldn't be maintaining a list of issues in wiki, it should be handled in the issue tracker. Well, you think it should after doing things in Jira anyway :) * Search sharing. There are probably other ones for other people, but for me I think it improves the speed in which we can identify open issues, which versions they're for etc. I'm getting better with Bugzilla now, but it still feel clunky. Sorry if I completely missed the point. Do not hesitate to correct me. Nope, you got the point. Just me wondering if consensus had moved to Jira now that Struts (well Martin was the one I was IMing) are Jira fans. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
On 4/25/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I know Jelly are on Jira already, and Struts have just moved over to Jira. Wondering what the view is nowadays on Commons moving to Jira? I am -1 on moving to jira. I dont understand why we - the open source developers and our users - should help testing a commercial application. And given that even for a mid-size company the minimum required license is the professional one - and its update policy - it is a rather expensive thing. Expensive? It's one of the least expensive enterprise-grade applications I've ever seen! At $4,800 for an enterprise license and a $2,400 annual upgrade, it's a steal. The serious competitors run into tens of thousands of dollars for an enterprise license. Also, JIRA is free for all non-profit and charitable organisations, and for open source. Also I dont understand whats the great benefit for us - compared to bugzilla - that we act as a marketing plattform for jira. We're no more a marketing platform for it than any of the other open source organisations that use it. As others have pointed out, many projects - and I do mean *many* projects - at the ASF already use it. See: http://issues.apache.org/jira/secure/Dashboard.jspa One other point: JIRA is a glowing example of what open source can do. It is built upon a ton of other open source projects, some of which were even founded by the JIRA authors themselves. As for features, I think the dashboard is very valuable, as is the project summary, and the ability to use it for planning and roadmap tracking in a *much* more usable manner than Bugzilla. -- Martin Cooper Sorry if I completely missed the point. Do not hesitate to correct me. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
Henri Yandell wrote: I know Jelly are on Jira already, and Struts have just moved over to Jira. Wondering what the view is nowadays on Commons moving to Jira? Hen I've been using Jira a lot over in Maven land and I like it. The visual appearance is so much more appealing than bugzilla, but its not just skin - there's substance as well. If all you ever do is file an issue now and then, then I agree that there is not that much difference between Jira and Bugzilla. But when you start to look at release management and road maps, I find Jira superior to Bugzilla. Just look at all the Release-plans for commons components on the wiki with hand-edited tables/lists of bugs that needs to be solved for this and that version. This is handled quite nicely by the built in functions in Jira. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
On 4/26/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I know Jelly are on Jira already, and Struts have just moved over to Jira. Wondering what the view is nowadays on Commons moving to Jira? I am -1 on moving to jira. I dont understand why we - the open source developers and our users - should help testing a commercial application. And given that even for a mid-size company the minimum required license is the professional one - and its update policy - it is a rather expensive thing. Also I dont understand whats the great benefit for us - compared to bugzilla - that we act as a marketing plattform for jira. Sorry if I completely missed the point. Do not hesitate to correct me. Ciao, Mario It doesn't make sense to be this adverse to commercial software if you agree with the ASL. If you truly have a distaste for commercial software then the GPL is probably more fitting with your goals. +0 I'm not that familar with Jira so I won't take a strong position but I'm all for removing bariers from getting stuff done. If Jira lets people do more with less effort then I'm all for it. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
Another advantage it's the possibility to customize your dashboard(s) with a lot of portlets. You can define what you want to see : the issues open, your votes, ... It's really useful for developers like us. Cheers. Arnaud (Maven's team) On 4/26/06, Henri Yandell [EMAIL PROTECTED] wrote: On 4/25/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I know Jelly are on Jira already, and Struts have just moved over to Jira. Wondering what the view is nowadays on Commons moving to Jira? I am -1 on moving to jira. Reason for mentioning Struts above was that I remembered that one of the -ve votes a few years ago on moving to Jira was from Martin and I thought some other Struts guys; thus the email to see if the consensus had moved. I'm +1 in favour of Jira, but not religious about it. I dont understand why we - the open source developers and our users - should help testing a commercial application. This is a common reason to not use Jira. From an ASF point of view, it's a bit weak I think. The ASF encourages companies to build commercial products on top of open-source software so using things like Jira is kind-of using our own dog-food. If Atlassin just offered Apache a licence, then it would be the kind of thing that we wouldnt accept. However if they offer it to everyone, then it's much the same kind of thing we push for at the JCP - open-source projects shouldn't be locked out due to lack of money. Also I dont understand whats the great benefit for us - compared to bugzilla - that we act as a marketing plattform for jira. Major advantages of Jira: * Project based administration - rather than central administration. * Visualization is much better - release management really shouldn't be maintaining a list of issues in wiki, it should be handled in the issue tracker. Well, you think it should after doing things in Jira anyway :) * Search sharing. There are probably other ones for other people, but for me I think it improves the speed in which we can identify open issues, which versions they're for etc. I'm getting better with Bugzilla now, but it still feel clunky. Sorry if I completely missed the point. Do not hesitate to correct me. Nope, you got the point. Just me wondering if consensus had moved to Jira now that Struts (well Martin was the one I was IMing) are Jira fans. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
Hi Sandy, It doesn't make sense to be this adverse to commercial software if you agree with the ASL. If you truly have a distaste for commercial software then the GPL is probably more fitting with your goals. I am not adverse to commercial software at all, we all have to make money. We also use tons of open source libraries for our application. I love the benefits of the ASL and this is why I am here :-) Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] Jira?
I know Jelly are on Jira already, and Struts have just moved over to Jira. Wondering what the view is nowadays on Commons moving to Jira? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
On 4/25/06, Henri Yandell [EMAIL PROTECTED] wrote: I know Jelly are on Jira already, and Struts have just moved over to Jira. Wondering what the view is nowadays on Commons moving to Jira? I used to be a -0.5 on moving to JIRA simply because it's not open source. However, having delved into JIRA more than a little, both on open source projects and in my day job, I've converted to a +1. There's a lot we could use it for that Bugzilla just doesn't do. -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd be +1 on the move. I'm not one who bashes Bugzilla for its faults, but Jira (license aside) is pretty nice to work with. [And the added 'features' that 'could' be utilized would be nice if they're used, too :-)] Brian Martin Cooper wrote: On 4/25/06, Henri Yandell [EMAIL PROTECTED] wrote: I know Jelly are on Jira already, and Struts have just moved over to Jira. Wondering what the view is nowadays on Commons moving to Jira? I used to be a -0.5 on moving to JIRA simply because it's not open source. However, having delved into JIRA more than a little, both on open source projects and in my day job, I've converted to a +1. There's a lot we could use it for that Bugzilla just doesn't do. -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFETwF6aCoPKRow/gARAmgeAKDum0lJVnN+sejW4FJK8Jone+ePlgCgzSKa xNR3T0uXNM3XouMR0FsdsDM= =RFd9 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
