You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Gert Vanthienen <ge...@skynet.be> on 2009/02/12 18:31:29 UTC
[DISCUSS] Separate JIRA project(s) for Components
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
Re: [DISCUSS] Separate JIRA project(s) for Components
Posted by Guillaume Nodet <gn...@gmail.com>.
I would go for one JIRA project and the current versionning scheme for
now, but this is not a strong opinion. I guess we can always split
things if needed later (especially if the number of components grow).
2009/2/12 Gert Vanthienen <ge...@skynet.be>:
> 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
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Separate JIRA project(s) for Components
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <ge...@skynet.be>:
> >>
> >>> 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
jbonofre@apache.org
jb@nanthrax.net
---------------------------------
OpenSource
BuildProcess/AutoDeploy
http://buildprocess.sourceforge.net
Apache ServiceMix
http://servicemix.apache.org
-----------------------------------
PGP : 17D4F086
Re: [DISCUSS] Separate JIRA project(s) for Components
Posted by Guillaume Nodet <gn...@gmail.com>.
Thanks guys !
On Sun, Feb 15, 2009 at 19:08, Gert Vanthienen
<ge...@skynet.be> 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 <ge...@skynet.be>:
>>>
>>>> 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.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Separate JIRA project(s) for Components
Posted by Gert Vanthienen <ge...@skynet.be>.
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 <ge...@skynet.be>:
>>
>>> 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.
Re: [DISCUSS] Separate JIRA project(s) for Components
Posted by Gert Vanthienen <ge...@skynet.be>.
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 <ge...@skynet.be>:
>
>> 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
>>>
>>>
>>>
>>
>
>
>
>
Re: [DISCUSS] Separate JIRA project(s) for Components
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <ge...@skynet.be>:
> 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
>>
>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Separate JIRA project(s) for Components
Posted by Gert Vanthienen <ge...@skynet.be>.
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
>
>
Re: [DISCUSS] Separate JIRA project(s) for Components
Posted by Chris Custine <ch...@gmail.com>.
I personally favor a Jira for each component, but I agree that it is not
realistic right now. I think its OK to start with large project for all
components for now and maybe we can evaluate options later. I think the
most important part is to document the individual comopnent releases very
well and possibly add release information to the individual component pages
in the wiki.
Chris
--
Chris Custine
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Directory Server :: http://directory.apache.org
On Thu, Feb 12, 2009 at 10:31 AM, Gert Vanthienen <gert.vanthienen@skynet.be
> 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
>
>
Re: [DISCUSS] Separate JIRA project(s) for Components
Posted by Freeman Fang <fr...@gmail.com>.
Hi Gert,
I prefer to one JIRA project for all components and keep the current
versioning rule of component
Best Regards
Freeman
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
>
>
Re: [DISCUSS] Separate JIRA project(s) for Components
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I think that having one Jira for all components (to begin) is more applicable right now.
Especially, it will be easier for the users to target the JIRA with component in general,
whereas sometime it can be difficult to identify the exact component involved.
Regards
JB
On Thursday 12 February 2009 - 20:06, Lars Heinemann wrote:
> Well...this is not easy to decide.
> I would prefer the JIRA per component solution but I also see a big
> overhead here and maybe
> it's not worth the time doing this if only 1-2 releases are done per
> component and year.
>
> So I would suggest starting with the single Jira for all components
> solution at the moment.
>
> What do the others think?
>
> Regards
> Lars
>
>
> Gert Vanthienen schrieb:
> > 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
> >
>
--
Jean-Baptiste Onofré (Nanthrax)
BuildProcess/AutoDeploy Project Leader
http://buildprocess.sourceforge.net
jb@nanthrax.net
PGP : 17D4F086
Re: [DISCUSS] Separate JIRA project(s) for Components
Posted by Lars Heinemann <lh...@apache.org>.
Well...this is not easy to decide.
I would prefer the JIRA per component solution but I also see a big
overhead here and maybe
it's not worth the time doing this if only 1-2 releases are done per
component and year.
So I would suggest starting with the single Jira for all components
solution at the moment.
What do the others think?
Regards
Lars
Gert Vanthienen schrieb:
> 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
>