Re: [VOTE] Division of Cocoon's JIRA project
Grzegorz Kossakowski wrote: Hi Nils, Nils Kaiser pisze: Well, there is even a nicer way to do this. Depending on which edition of JIRA Apache has, you could add a Custom field "Fix Version (Component)" and "Affects Version (Component)". You should be able to do searches and filters on the field then. Seems like a very nice solution. Using two custom fields "Affects Version (Component)" and "Fix Version (Component)" we could give up standard JIRA fields as they only cause unnecessary confusion. How others feel about such solution? +1 Ralph
Re: [VOTE] Division of Cocoon's JIRA project
Vadim Gritsenko wrote: Grzegorz Kossakowski wrote: Hi Nils, Nils Kaiser pisze: Well, there is even a nicer way to do this. Depending on which edition of JIRA Apache has, you could add a Custom field "Fix Version (Component)" and "Affects Version (Component)". You should be able to do searches and filters on the field then. Seems like a very nice solution. Using two custom fields "Affects Version (Component)" and "Fix Version (Component)" we could give up standard JIRA fields as they only cause unnecessary confusion. How others feel about such solution? no objections at all, +1 +1 as well -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc
Re: [VOTE] Division of Cocoon's JIRA project
Grzegorz Kossakowski wrote: Hi Nils, Nils Kaiser pisze: Well, there is even a nicer way to do this. Depending on which edition of JIRA Apache has, you could add a Custom field "Fix Version (Component)" and "Affects Version (Component)". You should be able to do searches and filters on the field then. Seems like a very nice solution. Using two custom fields "Affects Version (Component)" and "Fix Version (Component)" we could give up standard JIRA fields as they only cause unnecessary confusion. How others feel about such solution? no objections at all, +1 Vadim
Re: [VOTE] Division of Cocoon's JIRA project
Hi Nils, Nils Kaiser pisze: Well, there is even a nicer way to do this. Depending on which edition of JIRA Apache has, you could add a Custom field "Fix Version (Component)" and "Affects Version (Component)". You should be able to do searches and filters on the field then. Seems like a very nice solution. Using two custom fields "Affects Version (Component)" and "Fix Version (Component)" we could give up standard JIRA fields as they only cause unnecessary confusion. How others feel about such solution? In fact, I was asking myself of users would provide such detailled information anyway when they post a new issue. Even if internally, the software is made of components, a user will still download a version in the future - on a user's perspective, the bug will be affecting a cocoon version and not a component version. Up to date, when releasing Cocoon 2.2 we were focusing on releasing artifacts and putting them on Maven repository. Most of the time we assume (or at least advise) Maven is used so user already needs to deal with Cocoon artifacts' versions in her own pom. Moreover, Maven already provides nice tools to find out what versions are used so we are likely to ask users this information anyway. Without exact version of artifact (block) we will not be able to help in most cases, IMO. All in all, it's not a big deal to ask user to fire mvn project-info-reports:dependencies command. So maybe its more in the responsibily of the developers to recognize and manage the component version anyway... in that case the custom field solution seem to be enough in my opinion. Or telling user how to provide this information, se above. Another remark on the splitted JIRA projects approach: what about issues covering more than one component (for example, feature requests)? Or where the reporting user does not know which components the error belongs to? Or where the components are not existing yet? In that case it is much easier to correct the information when the issues are all in one project where you can add the component(s) affected by the issue. You and others have convinced me that splitting is not such a great idea as I thought previously. What about this solution? Anyway, thanks Nils for very useful comments!! -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ *** My Internet Service Provider breaks my internet connection *** *** incessantly so I'll not be able to respond to e-mails *** *** regularly and my work will be somehow irregular. *** *** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [VOTE] Division of Cocoon's JIRA project
Hey Vadim, Vadim Gritsenko schrieb: The answer is: no. It should start to search for cocoon-forms-impl:1.0.0-RC2 or cocoon-forms-impl:1.0.0. Open COCOON-2091, remove 'fix version', add comment: 'Fixed in cocoon-forms-impl:1.0.0-RC2', done. Personally, I'd not sweat over it that much - it's not that big of a deal. Vadim Well, there is even a nicer way to do this. Depending on which edition of JIRA Apache has, you could add a Custom field "Fix Version (Component)" and "Affects Version (Component)". You should be able to do searches and filters on the field then. In fact, I was asking myself of users would provide such detailled information anyway when they post a new issue. Even if internally, the software is made of components, a user will still download a version in the future - on a user's perspective, the bug will be affecting a cocoon version and not a component version. So maybe its more in the responsibily of the developers to recognize and manage the component version anyway... in that case the custom field solution seem to be enough in my opinion. Another remark on the splitted JIRA projects approach: what about issues covering more than one component (for example, feature requests)? Or where the reporting user does not know which components the error belongs to? Or where the components are not existing yet? In that case it is much easier to correct the information when the issues are all in one project where you can add the component(s) affected by the issue. Greetings, Nils
Re: [VOTE] Division of Cocoon's JIRA project
Grzegorz Kossakowski wrote: Take a look at COCOON-2091[1] issue, it has Fix version set to 2.2. Now if some user would like to take advantage of Xinha should start to search Maven repository for org.apache.cocoon:cocoon-forms-impl:2.2 right? I'd think he would open up changes log for cocoon-forms block and see where it was fixes. Alternatively, he would go to download section of the website and click on 'cocoon-2.2-bin.tar.gz'. But that's MHO. The answer is: no. It should start to search for cocoon-forms-impl:1.0.0-RC2 or cocoon-forms-impl:1.0.0. Open COCOON-2091, remove 'fix version', add comment: 'Fixed in cocoon-forms-impl:1.0.0-RC2', done. Personally, I'd not sweat over it that much - it's not that big of a deal. Vadim
Re: [VOTE] Division of Cocoon's JIRA project
Joerg Heinicke wrote: On 20.08.2007 15:08 Uhr, Grzegorz Kossakowski wrote: I really wouldn't like to be seen as crazy person blindly pushing us to this split up. To be honest, I would like to do nothing. Such split up is lots of work in JIRA itself, then fixing URLs in our poms, etc. My goal is simple: let our issue tracking have valid information about version particular issue affects and version where particular issue is fixed. You are not the only person. I'd prefer a better solution as well, but I change the camp since it does not seem to be worth the effort at the moment. You only move the problem from selecting the right version to selecting the right Jira project - and therefore break all the URLs. Some like issues linked in Jira comments themselves you can't even fix. I think in the meantime we should just leave it as is and hope for improvements in Jira itself like versions specific to components and not only projects. WDYT? +1 Ralph
Re: [VOTE] Division of Cocoon's JIRA project
On 20.08.2007 15:08 Uhr, Grzegorz Kossakowski wrote: Let's forget about independent releases. Take a look at COCOON-2091[1] issue, it has Fix version set to 2.2. Now if some user would like to take advantage of Xinha should start to search Maven repository for org.apache.cocoon:cocoon-forms-impl:2.2 right? The answer is: no. It should start to search for cocoon-forms-impl:1.0.0-RC2 or cocoon-forms-impl:1.0.0. Our 2.2 is almost completely useless because it only carries one information: this change does not affect 2.1.x branch, nothing more. This can be easily fixed by adding 1.0 to the list of versions. That's not really an issue, the actual one is to select the correct version from a big list. I really wouldn't like to be seen as crazy person blindly pushing us to this split up. To be honest, I would like to do nothing. Such split up is lots of work in JIRA itself, then fixing URLs in our poms, etc. My goal is simple: let our issue tracking have valid information about version particular issue affects and version where particular issue is fixed. You are not the only person. I'd prefer a better solution as well, but I change the camp since it does not seem to be worth the effort at the moment. You only move the problem from selecting the right version to selecting the right Jira project - and therefore break all the URLs. Some like issues linked in Jira comments themselves you can't even fix. I think in the meantime we should just leave it as is and hope for improvements in Jira itself like versions specific to components and not only projects. WDYT? Joerg
Re: [VOTE] Division of Cocoon's JIRA project
Vadim Gritsenko pisze: Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: Vadim, I may be biased in favour of JIRA because I use it quite extensively (as you can see yourself) but from my own experience JIRA offers us much more than plain text. Yes it does but you missed main point - JIRA and independent releases are not tied as tight as you think they are. Let's forget about independent releases. Take a look at COCOON-2091[1] issue, it has Fix version set to 2.2. Now if some user would like to take advantage of Xinha should start to search Maven repository for org.apache.cocoon:cocoon-forms-impl:2.2 right? The answer is: no. It should start to search for cocoon-forms-impl:1.0.0-RC2 or cocoon-forms-impl:1.0.0. Our 2.2 is almost completely useless because it only carries one information: this change does not affect 2.1.x branch, nothing more. Have you tried Mylyn (Mylar in the past)? I think that Mylyn is killer plug-in for Eclipse that makes task creation very easy and _natural_. I'm IDEA user, Eclipse does not work for me. As for the subject of the mail - I'm -0 myself: I don't see need to split up and I see issues with broken URLs, large and ugly prefixes, etc. In short, I see downsides but don't see an upside. I really wouldn't like to be seen as crazy person blindly pushing us to this split up. To be honest, I would like to do nothing. Such split up is lots of work in JIRA itself, then fixing URLs in our poms, etc. My goal is simple: let our issue tracking have valid information about version particular issue affects and version where particular issue is fixed. Unfortunately, JIRA does not support versions per component but only per project. My own opinion is that's rather funny to call product enterprise-ready without this feature (or substitute) especially that there is huge number of people asking for it. If we don't go this path, what is another? I think current situation is unacceptable. Just trying to give a perspective you haven't considered :) I have, I'm just out of other ideas... [1] https://issues.apache.org/jira/browse/COCOON-2091 -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ *** My Internet Service Provider breaks my internet connection *** *** incessantly so I'll not be able to respond to e-mails *** *** regularly and my work will be somehow irregular. *** *** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [VOTE] Division of Cocoon's JIRA project
Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: I would hazard a guess that impossibility to plan independent releases in JIRA, assign issues to specific version will be main cause for failing to do independent releases. We agreed long ago to do more time based releases and less feature based releases. There is no need for Jira to plan time based releases. Moreover, there is also no need for Jira to plan feature based releases as well. You can as easily use status.xml (see todo section) to track features needed for a particular release. Vadim, I may be biased in favour of JIRA because I use it quite extensively (as you can see yourself) but from my own experience JIRA offers us much more than plain text. Yes it does but you missed main point - JIRA and independent releases are not tied as tight as you think they are. Have you tried Mylyn (Mylar in the past)? I think that Mylyn is killer plug-in for Eclipse that makes task creation very easy and _natural_. I'm IDEA user, Eclipse does not work for me. As for the subject of the mail - I'm -0 myself: I don't see need to split up and I see issues with broken URLs, large and ugly prefixes, etc. In short, I see downsides but don't see an upside. Don't be. Think of a bright side - status.xml is easier and faster to edit than Jira! :) :) Let it be a joke ;) Just trying to give a perspective you haven't considered :) Vadim
Re: [VOTE] Division of Cocoon's JIRA project
Alfred Nathaniel wrote: On Sun, 2007-08-19 at 17:44 +0200, Reinhard Poetz wrote: What I mean is that one release cycle should have one Jira project. As soon as we have two modules that have _different_ release cycles and managed by _one_ Jira project, I don't understand what we gain compared to the status quo. Personally, I don't believe that the idea of different release cycles will fly for very long. In the end there will be the same sort of problems getting a grip on the version compatibilities which made the Eclipse people invent the Callisto approach. And with 100 open JIRA issues, I don't see the necessity of splitting into smaller parts. Splitting also assumes that the reporting user is able to pinpoint the part where his particular problems stems from. If he makes a mistake there, we can correct it by changing the project to which it refers -- but that breaks each time the URL. Talking about large list - you can already filter by component, so no splitting is necessary to achieve this. Vadim So here's my -0. Cheers, Alfred.
Re: [VOTE] Division of Cocoon's JIRA project
On Sun, 2007-08-19 at 17:44 +0200, Reinhard Poetz wrote: > What I mean is that one release cycle should have one Jira project. As soon > as > we have two modules that have _different_ release cycles and managed by _one_ > Jira project, I don't understand what we gain compared to the status quo. Personally, I don't believe that the idea of different release cycles will fly for very long. In the end there will be the same sort of problems getting a grip on the version compatibilities which made the Eclipse people invent the Callisto approach. And with 100 open JIRA issues, I don't see the necessity of splitting into smaller parts. Splitting also assumes that the reporting user is able to pinpoint the part where his particular problems stems from. If he makes a mistake there, we can correct it by changing the project to which it refers -- but that breaks each time the URL. So here's my -0. Cheers, Alfred.
Re: [VOTE] Division of Cocoon's JIRA project
On 19.08.2007 11:27 Uhr, Ralph Goers wrote: I don't want to see Cocoon portal under COCOON_BLOCKS only to have it changed later. This makes me realizing that there will be another drawback: All our bug references will be broken, e.g. in mails or status.xml. I guess associating an issue to another project is not a functionality provided by Jira meaning that COCOON-XYZ gets redirected to COCOON_CORE-ABC afterwards. It's probably done directly on the database. If that's true we should avoid to change it too often and need a good first shot - or avoid it at all and only introduce new Jira projects for new modules/projects like spring-configurator or servlet-service-framework. Joerg
Re: [VOTE] Division of Cocoon's JIRA project
Ralph Goers wrote: I don't want to see Cocoon portal under COCOON_BLOCKS only to have it changed later. I also don't understand the last sentence in Reinhard's email, "IMO we should either create them all or don't change anything because I don't understand what the benefit of having multiple Jira projects is if we can't use correct version numbers.". This implies that separate Jira projects can't have correct version numbers, which I don't recall ever hearing anything about. What I mean is that one release cycle should have one Jira project. As soon as we have two modules that have _different_ release cycles and managed by _one_ Jira project, I don't understand what we gain compared to the status quo. -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc
Re: [VOTE] Division of Cocoon's JIRA project
I don't want to see Cocoon portal under COCOON_BLOCKS only to have it changed later. I also don't understand the last sentence in Reinhard's email, "IMO we should either create them all or don't change anything because I don't understand what the benefit of having multiple Jira projects is if we can't use correct version numbers.". This implies that separate Jira projects can't have correct version numbers, which I don't recall ever hearing anything about. I'm not about to vote -1 on this proposal, but I'm also not seeing others enthusiastically endorsing this either. Ralph Grzegorz Kossakowski wrote: Reinhard Poetz pisze: If we can't get this piece of information, I'm +1 for setting up the 20+ projects (http://marc.info/?l=xml-cocoon-dev&m=118728284316195&w=2). To push this subject forward and do not spoil another vote I would like to ask you: a) are fine with proposal updated by Reinhard? b) are all doubts dispeled so you can vote with confidence?
Re: [VOTE] Division of Cocoon's JIRA project
Reinhard Poetz pisze: If we can't get this piece of information, I'm +1 for setting up the 20+ projects (http://marc.info/?l=xml-cocoon-dev&m=118728284316195&w=2). To push this subject forward and do not spoil another vote I would like to ask you: a) are fine with proposal updated by Reinhard? b) are all doubts dispeled so you can vote with confidence? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: [VOTE] Division of Cocoon's JIRA project
Grzegorz Kossakowski wrote: Have you tried Mylyn (Mylar in the past)? I think that Mylyn is killer plug-in for Eclipse that makes task creation very easy and _natural_. That wouldn't help me. I use (and advocate) IntelliJ. Ralph
Re: [VOTE] Division of Cocoon's JIRA project
Vadim Gritsenko pisze: I would hazard a guess that impossibility to plan independent releases in JIRA, assign issues to specific version will be main cause for failing to do independent releases. We agreed long ago to do more time based releases and less feature based releases. There is no need for Jira to plan time based releases. Moreover, there is also no need for Jira to plan feature based releases as well. You can as easily use status.xml (see todo section) to track features needed for a particular release. Vadim, I may be biased in favour of JIRA because I use it quite extensively (as you can see yourself) but from my own experience JIRA offers us much more than plain text. Sorry but I don't really understand if you are joking here but taking your course of argumentation we could say that version control system is redundant because we can do well with simple bash script that will make snapshots for us regularly. No need to install svn client, learn its commands, etc. JIRA offers nice, graphical overview over progress of particular release, can produce release notes automatically, and so on. Have you tried Mylyn (Mylar in the past)? I think that Mylyn is killer plug-in for Eclipse that makes task creation very easy and _natural_. Don't be. Think of a bright side - status.xml is easier and faster to edit than Jira! :) :) Let it be a joke ;) -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ *** My Internet Service Provider breaks my internet connection *** *** incessantly so I'll not be able to respond to e-mails *** *** regularly and my work will be somehow irregular. *** *** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [VOTE] Division of Cocoon's JIRA project
I feel a need to do some deFUDging here... Grzegorz Kossakowski wrote: On the other hand, current situation is also rather unacceptable because our current versions defined in JIRA do mean /nothing/. We all agree we need separate (and more often, sight...) release cycles and this *must* be expressed in JIRA. Why? I don't see any relation. Moreover, we can stop using Jira completely and still merrily do all our releases, with independent release cycles for all components. Jira does not help nor impede our ability to do so. I would hazard a guess that impossibility to plan independent releases in JIRA, assign issues to specific version will be main cause for failing to do independent releases. We agreed long ago to do more time based releases and less feature based releases. There is no need for Jira to plan time based releases. Moreover, there is also no need for Jira to plan feature based releases as well. You can as easily use status.xml (see todo section) to track features needed for a particular release. I may speaking about obvious things, but possibility to assign bugs to specific versions can improve situation both on developer's and user's. We could have a better idea of what's need to be done before we can release specific piece of code and our users would have a better idea when a specific issue will get fixed and how far we are from releasing something. I'm depressed... Don't be. Think of a bright side - status.xml is easier and faster to edit than Jira! :) Vadim
Re: [VOTE] Division of Cocoon's JIRA project
Reinhard Poetz wrote: Nils Kaiser wrote: By following the discussion I had a look wether JIRA people are planning to add some support in that direction and in fact there are some issues related to this: http://jira.atlassian.com/browse/JRA-12241 - Support for Product Suites / Sub-Projects (22 votes) http://jira.atlassian.com/browse/JRA-3228 - Ability to add versions to components (18 votes) While this does not add any solution to the problem, you could all vote for the issue or comment it. There are also a lot of duplicates... Thanks Nils for the research. Maybe it's best to wait for these features then and only create seperate Jira projects for our two subprojects (configuration, servlet-service). Do the Atlassian folks have some kind of public schedule that gives us a clue what they plan for the upcoming releases? If we can't get this piece of information, I'm +1 for setting up the 20+ projects (http://marc.info/?l=xml-cocoon-dev&m=118728284316195&w=2). -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc
Re: [VOTE] Division of Cocoon's JIRA project
Reinhard Poetz pisze: Thanks Nils for the research. Maybe it's best to wait for these features then and only create seperate Jira projects for our two subprojects (configuration, servlet-service). Do the Atlassian folks have some kind of public schedule that gives us a clue what they plan for the upcoming releases? Take a look at[1]. According to comments in these issues, if one is going to be addressed in near future it's going to have fix version set. Most of issues reporting demand for this feature are rather old, JRA-846 is five years old... I would not expect this feature implemented in the future we care of. [1] http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ *** My Internet Service Provider breaks my internet connection *** *** incessantly so I'll not be able to respond to e-mails *** *** regularly and my work will be somehow irregular. *** *** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [VOTE] Division of Cocoon's JIRA project
Hi Nils, Nils Kaiser pisze: And of course the most voted one was missing: http://jira.atlassian.com/browse/JRA-846 - Support for subcomponents (198 votes) Nils Kaiser schrieb: By following the discussion I had a look wether JIRA people are planning to add some support in that direction and in fact there are some issues related to this: http://jira.atlassian.com/browse/JRA-12241 - Support for Product Suites / Sub-Projects (22 votes) http://jira.atlassian.com/browse/JRA-3228 - Ability to add versions to components (18 votes) While this does not add any solution to the problem, you could all vote for the issue or comment it. There are also a lot of duplicates... Thanks for providing us this info. The situation looks quite depressing as this issue seems to not going to be addressed in near future. People's comments already expressed concerns about multiple projects approach. They bloat Dashboard page and cause management problems because projects that are related when it comes to functionality and making releases completely lack this information in JIRA. It's exactly an issue which what Ralph raised[1]. On the other hand, current situation is also rather unacceptable because our current versions defined in JIRA do mean /nothing/. We all agree we need separate (and more often, sight...) release cycles and this *must* be expressed in JIRA. I would hazard a guess that impossibility to plan independent releases in JIRA, assign issues to specific version will be main cause for failing to do independent releases. I may speaking about obvious things, but possibility to assign bugs to specific versions can improve situation both on developer's and user's. We could have a better idea of what's need to be done before we can release specific piece of code and our users would have a better idea when a specific issue will get fixed and how far we are from releasing something. I'm depressed... [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74601 -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ *** My Internet Service Provider breaks my internet connection *** *** incessantly so I'll not be able to respond to e-mails *** *** regularly and my work will be somehow irregular. *** *** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [VOTE] Division of Cocoon's JIRA project
Nils Kaiser wrote: By following the discussion I had a look wether JIRA people are planning to add some support in that direction and in fact there are some issues related to this: http://jira.atlassian.com/browse/JRA-12241 - Support for Product Suites / Sub-Projects (22 votes) http://jira.atlassian.com/browse/JRA-3228 - Ability to add versions to components (18 votes) While this does not add any solution to the problem, you could all vote for the issue or comment it. There are also a lot of duplicates... Thanks Nils for the research. Maybe it's best to wait for these features then and only create seperate Jira projects for our two subprojects (configuration, servlet-service). Do the Atlassian folks have some kind of public schedule that gives us a clue what they plan for the upcoming releases? -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc
Re: [VOTE] Division of Cocoon's JIRA project
And of course the most voted one was missing: http://jira.atlassian.com/browse/JRA-846 - Support for subcomponents (198 votes) Nils Kaiser schrieb: By following the discussion I had a look wether JIRA people are planning to add some support in that direction and in fact there are some issues related to this: http://jira.atlassian.com/browse/JRA-12241 - Support for Product Suites / Sub-Projects (22 votes) http://jira.atlassian.com/browse/JRA-3228 - Ability to add versions to components (18 votes) While this does not add any solution to the problem, you could all vote for the issue or comment it. There are also a lot of duplicates... Greetings, Nils Reinhard Poetz schrieb: Grzegorz Kossakowski wrote: Reinhard Poetz pisze: hmmm, the main benefit of having seperate Jira projects is that we can have seperate version numbering schemes for each project. But looking at e.g. COCOONM2 I don't see how this can be achieved because all modules that it contains already have different version numbers. If I want to report a bug I don't know which version number I have to choose. So what can we do? Split into more projects?
Re: [VOTE] Division of Cocoon's JIRA project
By following the discussion I had a look wether JIRA people are planning to add some support in that direction and in fact there are some issues related to this: http://jira.atlassian.com/browse/JRA-12241 - Support for Product Suites / Sub-Projects (22 votes) http://jira.atlassian.com/browse/JRA-3228 - Ability to add versions to components (18 votes) While this does not add any solution to the problem, you could all vote for the issue or comment it. There are also a lot of duplicates... Greetings, Nils Reinhard Poetz schrieb: Grzegorz Kossakowski wrote: Reinhard Poetz pisze: hmmm, the main benefit of having seperate Jira projects is that we can have seperate version numbering schemes for each project. But looking at e.g. COCOONM2 I don't see how this can be achieved because all modules that it contains already have different version numbers. If I want to report a bug I don't know which version number I have to choose. So what can we do? Split into more projects?
Re: [VOTE] Division of Cocoon's JIRA project
Grzegorz Kossakowski wrote: Reinhard Poetz pisze: hmmm, the main benefit of having seperate Jira projects is that we can have seperate version numbering schemes for each project. But looking at e.g. COCOONM2 I don't see how this can be achieved because all modules that it contains already have different version numbers. If I want to report a bug I don't know which version number I have to choose. So what can we do? Split into more projects? honestly, I don't know what's the best solution for our situation is. Looking at the latest release we would need following Jira projects: COCOON_CORE - org.apache.cocoon:cocoon-pipeline-api:1.0.0-RC1 - org.apache.cocoon:cocoon-util:1.0.0-RC1 - org.apache.cocoon:cocoon-xml-api:1.0.0-RC1 - org.apache.cocoon:cocoon-pipeline-impl:1.0.0-RC1 - org.apache.cocoon:cocoon-xml-impl:1.0.0-RC1 - org.apache.cocoon:cocoon-pipeline-components:1.0.0-RC1 - org.apache.cocoon:cocoon-sitemap-api:1.0.0-RC1 - org.apache.cocoon:cocoon-thread-api:1.0.0-RC1 - org.apache.cocoon:cocoon-sitemap-impl:1.0.0-RC1 - org.apache.cocoon:cocoon-sitemap-components:1.0.0-RC1 - org.apache.cocoon:cocoon-xml-resolver:1.0.0-RC1 - org.apache.cocoon:cocoon-store-impl:1.0.0-RC1 - org.apache.cocoon:cocoon-thread-impl:1.0.0-RC1 - org.apache.cocoon:cocoon-core:2.2.0-RC1 COCOON_SERVLETSERVICE - org.apache.cocoon:cocoon-servlet-service-components:1.0.0-M2 - org.apache.cocoon:cocoon-servlet-service-impl:1.0.0-M2 COCOON_FORMS - org.apache.cocoon:cocoon-flowscript-impl:1.0.0-RC1 COCOON_TEMPLATE - org.apache.cocoon:cocoon-template-impl:1.0.0-RC1 COCOON_APPLES - org.apache.cocoon:cocoon-apples-impl:1.0.0-RC1 COCOON_LINKREWRITE - org.apache.cocoon:cocoon-linkrewriter-impl:1.0.0-RC1 COCOON_AUTH - org.apache.cocoon:cocoon-auth-api:1.0.0-RC1 - org.apache.cocoon:cocoon-auth-impl:1.0.0-RC1 COCOON_BATIK - org.apache.cocoon:cocoon-batik-impl:1.0.0-RC1 COCOON_CAPTCHA - org.apache.cocoon:cocoon-captcha-impl:1.0.0-RC1 COCOON_DATABASE - org.apache.cocoon:cocoon-databases-mocks:1.0.0-RC1 - org.apache.cocoon:cocoon-databases-impl:1.0.0-RC1 COCOON_HSQLDB - org.apache.cocoon:cocoon-databases-hsqldb-client:1.0.0-RC1 - org.apache.cocoon:cocoon-databases-hsqldb-server:1.0.0-RC1 COCOON_FLOWSCRIPT - org.apache.cocoon:cocoon-flowscript-impl:1.0.0-RC1 COCOON_FOP - org.apache.cocoon:cocoon-fop-impl:1.0.0-RC1 COCOON_HTML - org.apache.cocoon:cocoon-html-impl:1.0.0-RC1 COCOON_MAIL - org.apache.cocoon:cocoon-mail-impl:1.0.0-RC1 COCOON_FORMS - org.apache.cocoon:cocoon-forms-impl:1.0.0-M3 COCOON_AJAX - org.apache.cocoon:cocoon-ajax-impl:1.0.0-M3 COCOON_M2 - org.apache.cocoon:cocoon-maven-plugin:1.0.0-M1 - org.apache.cocoon:cocoon-rcl-spring-reloader:1.0.0-M1 - org.apache.cocoon:cocoon-rcl-webapp-wrapper:1.0.0-M1 COCOON_M2_ARCHETYPES - org.apache.cocoon:cocoon-22-archetype-block:1.0.0-RC1 - org.apache.cocoon:cocoon-22-archetype-block-plain:1.0.0-RC1 - org.apache.cocoon:cocoon-22-archetype-webapp:1.0.0-RC1 # COCOON_CONFIGURATION - org.apache.cocoon:cocoon-configuration-api:1.0.0 - org.apache.cocoon:spring-configurator:1.0.0 COCOON_BLOCKS -> the rest of the issues which belong to a block that hasn't it's own Jira project yet because it is not ready to be released. These are ~20 Jira projects. IMO we should either create them all or don't change anything because I don't understand what the benefit of having multiple Jira projects is if we can't use correct version numbers. -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc
Re: [VOTE] Division of Cocoon's JIRA project
Joerg Heinicke wrote: hmmm, the main benefit of having seperate Jira projects is that we can have seperate version numbering schemes for each project. I think it makes sense to not introduce a separate Jira project for EVERY project that might have (or already has) a different version number. See also COCOONBLOCKS above. Having the list of versions reduced to a meaningful set of this group is already advantageous. What's the benefit of having seperate Jira projects for a group of Cocoon modules compared to our current situation of having components in Jira? -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc
Re: [VOTE] Division of Cocoon's JIRA project
I really do not understand the advantage of this. Right now when I log into Jira and select Cocoon I can see all the Cocoon blocks. Obviously being able to associate an issue with a block or search or filter by block is therefore not an issue. The reason I keep hearing is that this should be done so that each block can be independently versioned. But I don't see why that can't be done now. Can we not just create versions such as Ajax-1.0? On the down side, right now if I log into Jira I can see all the Cocoon issues fairly easily. Is there any way to do that once they are split? Furthermore, I already don't like that the list of projects on the main page is riddled with a bunch of stuff from Commons. But at least there everyone knows that Commons is just a bunch of Java utilities, each of which is independent of each other. In our case this isn't really true. If, in fact, any of the items in the list below is truly independent perhaps it should be split from Cocoon entirely, not just in Jira. For example, I recall that Spring configurator would fit into this category. Ralph Grzegorz Kossakowski wrote: Hi, We have discussed JIRA split up several times now, the last time in this thread[1]. Since infra team raised concerns on proposed JIRA project identifier we agreed on adding "COCOON" prefix to every identifier. I posted updated proposal with topic "Division of Cocoon's JIRA once again" asking if there are any objections and for month there have been none. I would like call vote on division of Cocoon's JIRA project into several smaller ones as outlined below. The list of projects with proposed JIRA identifiers in brackets: - Cocoon Core (COCOONCORE) includes following artifacts: * org.apache.cocoon:cocoon-pipeline-api * org.apache.cocoon:cocoon-util * org.apache.cocoon:cocoon-xml-api * org.apache.cocoon:cocoon-pipeline-impl * org.apache.cocoon:cocoon-xml-impl * org.apache.cocoon:cocoon-pipeline-components * org.apache.cocoon:cocoon-sitemap-api * org.apache.cocoon:cocoon-thread-api * org.apache.cocoon:cocoon-sitemap-impl * org.apache.cocoon:cocoon-sitemap-components * org.apache.cocoon:cocoon-xml-resolver * org.apache.cocoon:cocoon-store-impl * org.apache.cocoon:cocoon-thread-impl * org.apache.cocoon:cocoon-core * org.apache.cocoon:cocoon-core-main-sample * org.apache.cocoon:cocoon-expression-language-api * org.apache.cocoon:cocoon-expression-language-impl - Servlet service framework (COCOONSERVLETSERVICE) * org.apache.cocoon:cocoon-servlet-service-components * org.apache.cocoon:cocoon-servlet-service-impl * org.apache.cocoon:cocoon-servlet-service-sample - Template (COCOONTEMPLATE) * org.apache.cocoon:cocoon-template-impl * org.apache.cocoon:cocoon-template-sample - Flowscript (COCOONFLOWSCRIPT) * org.apache.cocoon:cocoon-flowscript-impl - Database (COCOONDATABASE) * org.apache.cocoon:cocoon-databases-mocks * org.apache.cocoon:cocoon-databases-hsqldb-server * org.apache.cocoon:cocoon-databases-hsqldb-client * org.apache.cocoon:cocoon-databases-impl - Forms (COCOONFORMS) * org.apache.cocoon:cocoon-forms-impl * org.apache.cocoon:cocoon-forms-sample - M2 Plugins and archetypes (COCOONM2) * org.apache.cocoon:cocoon-maven-plugin * org.apache.cocoon:cocoon-rcl-spring-reloader * org.apache.cocoon:cocoon-rcl-webapp-wrapper * org.apache.cocoon:cocoon-22-archetype-block * org.apache.cocoon:cocoon-22-archetype-block-plain * org.apache.cocoon:cocoon-22-archetype-webapp Please cast your votes! [1] http://thread.gmane.org/gmane.text.xml.cocoon.devel/73844
Re: [VOTE] Division of Cocoon's JIRA project
Felix Knecht pisze: I don't think that only released blocks will produce JIRA entries. Where shall then JIRA entries for unreleased blocks goto? And what happens with them when a block is released? Will the be moved into the new created JIRA project for the newly released block? There will be still COCOON project that should be treated both as legacy and sink project. If there is no suitable JIRA project, create issue at COCOON. As long as issues will be tied to some component in COCOON project it will be relatively easy to move all of them to the a created project. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ *** My Internet Service Provider breaks my internet connection *** *** incessantly so I'll not be able to respond to e-mails *** *** regularly and my work will be somehow irregular. *** *** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [VOTE] Division of Cocoon's JIRA project
>> - why separate projects for some blocks? Why exactly these? > > I've taken list of modules and blocks released by Reinhard as RC1 and > collated with this [1] report. > > I think that we should create separate JIRA projects for artifacts > that are already released. Especially if creation of all projects > would be troublesome (believe me, it's a lot of work). > >> - what about the remaining blocks? > > As soon as new blocks are released we can call a new vote. I wanted to > focus on piece doable for me and Joerg (assuming his offer to help is > still open). I don't think that only released blocks will produce JIRA entries. Where shall then JIRA entries for unreleased blocks goto? And what happens with them when a block is released? Will the be moved into the new created JIRA project for the newly released block?
Re: [VOTE] Division of Cocoon's JIRA project
Reinhard Poetz pisze: hmmm, the main benefit of having seperate Jira projects is that we can have seperate version numbering schemes for each project. But looking at e.g. COCOONM2 I don't see how this can be achieved because all modules that it contains already have different version numbers. If I want to report a bug I don't know which version number I have to choose. So what can we do? Split into more projects? Apart fromt that I miss COCOONCONFIGURATION. (Btw, would it be possible to use underlines, e.g. COCOON_CONFIGURATION to increase readability?) According to http://www.atlassian.com/software/jira/docs/latest/project_keys.html#Project+Key+Pattern it's configurable so we would have to ask infra for configuration details on Apache. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ *** My Internet Service Provider breaks my internet connection *** *** incessantly so I'll not be able to respond to e-mails *** *** regularly and my work will be somehow irregular. *** *** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [VOTE] Division of Cocoon's JIRA project
Carsten Ziegeler pisze: I don't want to slow down this vote, but looking at the list, I have several questions: I already slowed down it for so long so don't worry ;) - why are some modules from cocoon core not listed under cocooncore? Which ones? After taking a look at components at this page: https://issues.apache.org/jira/browse/COCOON I see that I forgot to mention that all remaining components under Core will be moved to COCOONCORE. - why a separate Jira project for the servletservice? and why not for others that mind stand on their own? Servlet service is subproject. I guess you have in mind configurator, right? If so, I agree with you that it should have its own JIRA project. I just forgot about it. On the other, this vote is about _dividing_ existing COCOON project. Since there is no corresponding component for configurator subproject there is nothing to divide. I agree that we should create separate JIRA project but we should vote it separately, IMO. - why separate projects for some blocks? Why exactly these? I've taken list of modules and blocks released by Reinhard as RC1 and collated with this [1] report. I think that we should create separate JIRA projects for artifacts that are already released. Especially if creation of all projects would be troublesome (believe me, it's a lot of work). - what about the remaining blocks? As soon as new blocks are released we can call a new vote. I wanted to focus on piece doable for me and Joerg (assuming his offer to help is still open). [1] http://people.apache.org/~gkossakowski/Cocoon%20issues%20from%20last%20120%20days.png -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ *** My Internet Service Provider breaks my internet connection *** *** incessantly so I'll not be able to respond to e-mails *** *** regularly and my work will be somehow irregular. *** *** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [VOTE] Division of Cocoon's JIRA project
On 15.08.2007 8:13 Uhr, Carsten Ziegeler wrote: - why are some modules from cocoon core not listed under cocooncore? - why a separate Jira project for the servletservice? and why not for others that mind stand on their own? - why separate projects for some blocks? Why exactly these? - what about the remaining blocks? These are probably the so-called "core blocks" that we are going to release with Cocoon Core 2.2. If other blocks justify their own project in the future we can add them as well. The most important should be to get a start. The list only lacks a project for all the "other blocks", COCOONBLOCKS should be ok. On 15.08.2007 8:18 Uhr, Reinhard Poetz wrote: hmmm, the main benefit of having seperate Jira projects is that we can have seperate version numbering schemes for each project. I think it makes sense to not introduce a separate Jira project for EVERY project that might have (or already has) a different version number. See also COCOONBLOCKS above. Having the list of versions reduced to a meaningful set of this group is already advantageous. Apart fromt that I miss COCOONCONFIGURATION. Seems to be a good addition. (Btw, would it be possible to use underlines, e.g. COCOON_CONFIGURATION to increase readability?) I guess it's not possible. None of the Apache Jira project keys has another char than the alphas. This is also true for Spring and Hibernate. Joerg
Re: [VOTE] Division of Cocoon's JIRA project
Grzegorz Kossakowski wrote: Hi, We have discussed JIRA split up several times now, the last time in this thread[1]. Since infra team raised concerns on proposed JIRA project identifier we agreed on adding "COCOON" prefix to every identifier. I posted updated proposal with topic "Division of Cocoon's JIRA once again" asking if there are any objections and for month there have been none. I would like call vote on division of Cocoon's JIRA project into several smaller ones as outlined below. The list of projects with proposed JIRA identifiers in brackets: - Cocoon Core (COCOONCORE) includes following artifacts: * org.apache.cocoon:cocoon-pipeline-api * org.apache.cocoon:cocoon-util * org.apache.cocoon:cocoon-xml-api * org.apache.cocoon:cocoon-pipeline-impl * org.apache.cocoon:cocoon-xml-impl * org.apache.cocoon:cocoon-pipeline-components * org.apache.cocoon:cocoon-sitemap-api * org.apache.cocoon:cocoon-thread-api * org.apache.cocoon:cocoon-sitemap-impl * org.apache.cocoon:cocoon-sitemap-components * org.apache.cocoon:cocoon-xml-resolver * org.apache.cocoon:cocoon-store-impl * org.apache.cocoon:cocoon-thread-impl * org.apache.cocoon:cocoon-core * org.apache.cocoon:cocoon-core-main-sample * org.apache.cocoon:cocoon-expression-language-api * org.apache.cocoon:cocoon-expression-language-impl - Servlet service framework (COCOONSERVLETSERVICE) * org.apache.cocoon:cocoon-servlet-service-components * org.apache.cocoon:cocoon-servlet-service-impl * org.apache.cocoon:cocoon-servlet-service-sample - Template (COCOONTEMPLATE) * org.apache.cocoon:cocoon-template-impl * org.apache.cocoon:cocoon-template-sample - Flowscript (COCOONFLOWSCRIPT) * org.apache.cocoon:cocoon-flowscript-impl - Database (COCOONDATABASE) * org.apache.cocoon:cocoon-databases-mocks * org.apache.cocoon:cocoon-databases-hsqldb-server * org.apache.cocoon:cocoon-databases-hsqldb-client * org.apache.cocoon:cocoon-databases-impl - Forms (COCOONFORMS) * org.apache.cocoon:cocoon-forms-impl * org.apache.cocoon:cocoon-forms-sample - M2 Plugins and archetypes (COCOONM2) * org.apache.cocoon:cocoon-maven-plugin * org.apache.cocoon:cocoon-rcl-spring-reloader * org.apache.cocoon:cocoon-rcl-webapp-wrapper * org.apache.cocoon:cocoon-22-archetype-block * org.apache.cocoon:cocoon-22-archetype-block-plain * org.apache.cocoon:cocoon-22-archetype-webapp hmmm, the main benefit of having seperate Jira projects is that we can have seperate version numbering schemes for each project. But looking at e.g. COCOONM2 I don't see how this can be achieved because all modules that it contains already have different version numbers. If I want to report a bug I don't know which version number I have to choose. Apart fromt that I miss COCOONCONFIGURATION. (Btw, would it be possible to use underlines, e.g. COCOON_CONFIGURATION to increase readability?) -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc
Re: [VOTE] Division of Cocoon's JIRA project
I don't want to slow down this vote, but looking at the list, I have several questions: - why are some modules from cocoon core not listed under cocooncore? - why a separate Jira project for the servletservice? and why not for others that mind stand on their own? - why separate projects for some blocks? Why exactly these? - what about the remaining blocks? Carsten Grzegorz Kossakowski wrote: > Hi, > > We have discussed JIRA split up several times now, the last time in this > thread[1]. Since infra team raised concerns on proposed JIRA project > identifier we agreed on adding "COCOON" prefix to every identifier. I > posted updated proposal with topic "Division of Cocoon's JIRA once > again" asking if there are any objections and for month there have been > none. > > I would like call vote on division of Cocoon's JIRA project into several > smaller ones as outlined below. > The list of projects with proposed JIRA identifiers in brackets: > - Cocoon Core (COCOONCORE) > includes following artifacts: > * org.apache.cocoon:cocoon-pipeline-api > * org.apache.cocoon:cocoon-util > * org.apache.cocoon:cocoon-xml-api > * org.apache.cocoon:cocoon-pipeline-impl > * org.apache.cocoon:cocoon-xml-impl > * org.apache.cocoon:cocoon-pipeline-components > * org.apache.cocoon:cocoon-sitemap-api > * org.apache.cocoon:cocoon-thread-api > * org.apache.cocoon:cocoon-sitemap-impl > * org.apache.cocoon:cocoon-sitemap-components > * org.apache.cocoon:cocoon-xml-resolver > * org.apache.cocoon:cocoon-store-impl > * org.apache.cocoon:cocoon-thread-impl > * org.apache.cocoon:cocoon-core > * org.apache.cocoon:cocoon-core-main-sample > * org.apache.cocoon:cocoon-expression-language-api > * org.apache.cocoon:cocoon-expression-language-impl > - Servlet service framework (COCOONSERVLETSERVICE) > * org.apache.cocoon:cocoon-servlet-service-components > * org.apache.cocoon:cocoon-servlet-service-impl > * org.apache.cocoon:cocoon-servlet-service-sample > - Template (COCOONTEMPLATE) > * org.apache.cocoon:cocoon-template-impl > * org.apache.cocoon:cocoon-template-sample > - Flowscript (COCOONFLOWSCRIPT) > * org.apache.cocoon:cocoon-flowscript-impl > - Database (COCOONDATABASE) > * org.apache.cocoon:cocoon-databases-mocks > * org.apache.cocoon:cocoon-databases-hsqldb-server > * org.apache.cocoon:cocoon-databases-hsqldb-client > * org.apache.cocoon:cocoon-databases-impl > - Forms (COCOONFORMS) > * org.apache.cocoon:cocoon-forms-impl > * org.apache.cocoon:cocoon-forms-sample > - M2 Plugins and archetypes (COCOONM2) > * org.apache.cocoon:cocoon-maven-plugin > * org.apache.cocoon:cocoon-rcl-spring-reloader > * org.apache.cocoon:cocoon-rcl-webapp-wrapper > * org.apache.cocoon:cocoon-22-archetype-block > * org.apache.cocoon:cocoon-22-archetype-block-plain > * org.apache.cocoon:cocoon-22-archetype-webapp > > Please cast your votes! > > [1] http://thread.gmane.org/gmane.text.xml.cocoon.devel/73844 > -- Carsten Ziegeler [EMAIL PROTECTED]