Thanks to you Gert (I have done quite nothing :)). Regards JB
On Sunday 15 February 2009 - 10:08, Gert Vanthienen wrote: > > L.S., > > A separate JIRA project has been set up and components issues have been > moved to https://issues.apache.org/activemq/browse/SMXCOMP. The 2008.01 and > 2009.01 versions have been removed from our main ServiceMix JIRA, so we have > a more manageable list of versions there now as well. > > Thanks to Lars and Jean-Baptiste for helping me to get all the issues moved > over the weekend! > > Gert > > > > Gert Vanthienen wrote: > > > > Guillaume, > > > > Creating the release notes wouldn't be a real problem, I think. We're > > not doing this every week and we can always filter for a list of issues > > being solved for one specific component and one specific version and > > export that to text or something. > > > > However, you're right about the other thing... Confusing people about > > which version a fix should/would go in would be very bad indeed. If we > > get inconsistent release information in JIRA, it will become impossible > > to ever figure out if/when a user reported bug is getting fixed. We > > should prefer confusing people with 50-something different versions > > then, because at least that gives us the specific information we need > > for helping them out. > > > > Setting up a different project for every component right now would not > > be that much more work -- the only overhead would be in creating the > > projects themselves, we still need to create the same amount of versions > > and move all the issues around anyway. I'm a bit worried that this will > > scatter information around too much though and that it will become too > > difficult to get an overview of what we're doing. Also, nobody is going > > to notice that ActiveMQ and Camel are also around in this JIRA instance > > if we will add about 25 projects in there ;) > > > > So, unless there are any other thoughts, I'll set up a single project > > with the required amount of versions to cover all the components over > > the weekend. > > > > Regards, > > > > Gert > > > > Guillaume Nodet wrote: > >> I'm not sure how we could go with a single version. Suppose we create > >> a version for 2009.01 and 2009.02. If we release one component with > >> 2009.01, when a new JIRA is created, you will need to select a version > >> to fix the bug in, and you will end up choosing between 2 unreleased > >> versions. Another problem would be when we want to create the release > >> notes I guess. Having a single version would be nice because we would > >> not have a very long list of versions available, but it may very well > >> lead to inconsistencies if we are not very carefull to check the real > >> version when we fix a bug. > >> Though if we plan to later separate the components, using a single > >> version will be easier because we would not have to change those when > >> splitting the components. > >> > >> 2009/2/13 Gert Vanthienen <[email protected]>: > >> > >>> L.S., > >>> > >>> Looks like we agree to put things in a single JIRA project for all the > >>> components for now. Personally, I would prefer to use the plain version > >>> numbers, because we'd otherwise end up with another endless list of > >>> releases (servicemix-ftp-2008.01, servicemix-jms-2008.01, ....) in the > >>> new JIRA project. The only drawback I see is that we'd also have to > >>> create shared filters to get some kind of roadmap per component. Is > >>> there any obvious problem with using plain versions that I'm missing? > >>> > >>> +1 on Chris' suggestion to add better release information for the > >>> components to the wiki as well, that will also help in getting the > >>> release information for the containers out -- we could just point to the > >>> release notes of the components we include instead of having to > >>> aggregate the data from both JIRA projects. > >>> > >>> I'll try to migrate things over the weekend once we get a consensus on > >>> the versioning scheme. I guess we best move a bit of history for the > >>> components' issues as well (those that carry the odd version numbers) so > >>> we can get a clean JIRA project for the ServiceMix 3 container again. > >>> > >>> Regards, > >>> > >>> Gert > >>> > >>> Gert Vanthienen wrote: > >>> > >>>> L.S., > >>>> > >>>> If we look at the ServiceMix 3 JIRA project, the list of releases in > >>>> there is getting very long and very hard to work with. I know we > >>>> discussed this before, but I really think it makes sense to make a > >>>> separate JIRA project or projects for the components now. > >>>> One solution would be to create a single JIRA project for all the > >>>> components. Because we can release components independently, the > >>>> version numbers on the components will be going out of sync. One way > >>>> to handle this, is by using the same versioning scheme as we are using > >>>> now in SMX3, e.g. servicemix-ftp-2008.01 for version 2008.01 of > >>>> servicemix-ftp. On the other hand, we could also just create plain > >>>> version numbers like 2009.01 and then keeping the release open in JIRA > >>>> until all components have reached that version. > >>>> > >>>> The other way to get passed this would be to create a JIRA project per > >>>> component. This way, we could use versions in JIRA just as we are used > >>>> to, but the overhead of setting this up would be quite big. > >>>> > >>>> Which solution would people prefer? Are there any other suggestions > >>>> for solving this? > >>>> > >>>> Regards, > >>>> > >>>> Gert > >>>> > >>>> > >>>> > >>> > >> > >> > >> > >> > > > > > > > > ----- > > --- > > Gert Vanthienen > > http://gertvanthienen.blogspot.com > > > > > ----- > --- > Gert Vanthienen > http://gertvanthienen.blogspot.com > -- > View this message in context: > http://www.nabble.com/-DISCUSS--Separate-JIRA-project%28s%29-for-Components-tp21980838p22025458.html > Sent from the ServiceMix - Dev mailing list archive at Nabble.com. > -- Jean-Baptiste Onofré --------------------------------- HomePage http://www.nanthrax.net --------------------------------- Contacts [email protected] [email protected] --------------------------------- OpenSource BuildProcess/AutoDeploy http://buildprocess.sourceforge.net Apache ServiceMix http://servicemix.apache.org ----------------------------------- PGP : 17D4F086
