About ActiveMQ 5.3 and issues management

[ffrenchm <ff...@gmail.com>]

Hello,

I noticed that many issue from ActiveMQ 5.3 has been moved to ActiveMQ 5.4
and unscheduled. So I've the impression that ActiveMQ 5.3 will be delivered
soon. Am I false ? Where can I find the schedule of ActiveMQ 5.3 delivery ?

I noticed that for ActiveMQ 5.2 the delivery is based on a svn TAG. That's
mean no patch or SP delivery on this version. Will you apply the same policy
for ActiveMQ 5.3 ?

Finally I noticed that the issues I raised like many others has been moved
to 'unscheduled'. My problem is that for one of these issues (AMQ-2216) I
provided a correction with JUNIT test and I'm currently using ActiveMQ 5.3
with this correction. The aim of my work is to make work ActiveMQ at
production. 
So I would like to get a feed back from ActiveMQ experts on this correction
and I would like to know your point on how I'm supposed to deliver ActiveMQ
if this correction is not scheduled on any ActiveMQ delivery ? From my point
it seems I need to work independently on ActiveMQ source code and finally
deliver a forked ActiveMQ which finally means:

+ a dubious correction report from ActiveMQ trunk on my side.
+ a fall of my motivation to provide correction and JUNIT test in order to
help ActiveMQ community as it's not enough to get a quicker resolution on my
issue.
+ finally a fall of potential commiters on ActiveMQ side (in this case me
because 'never say never' :).

I don't like this solution because I prefer to work with the ActiveMQ
community as much as possible. But as I've also delivery deadline I must
choose the most proper way to achieve my aim and today it's seems for me the
most proper way is to fork ActiveMQ on my side and work independently on
this fork. 

Thanks for your answers
-- 
View this message in context: http://www.nabble.com/About-ActiveMQ-5.3-and-issues-management-tp24516761p24516761.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Re: About ActiveMQ 5.3 and issues management

[ffrenchm <ff...@gmail.com>]

Thanks for you answer Gary... 

You're increasing my motivation to continue my effort on activemq and that's
make me very happy :) Some others issues with corrections and JUNIT tests
should come soon :)

++


Gary Tully wrote:
> 
> There is no schedule as such, save that I think we should wait till
> camel 2.0 is released and the outstanding (13) scheduled issues from
> http://issues.apache.org/activemq/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10520&fixfor=11914
> are resolved along with anything critical that pops up in the mean
> time. It is very hard to put an exact time line on this, in addition,
> the testing that follow a release candidate can often precipitate new
> issues.
> 
> The push out of issues to 5.3.4 was the first effort to constrain the
> release. I tried to retain any issue that had a patch and junit test.
> Part of the intention was to solicit response, so in your case, it
> looks like AMQ-2216 should be reinstated as fix for 5.3.
> 
> We welcome, appreciate and want to encourage your contribution so
> apologies if it looked like it was being ignored.
> 
> 2009/7/16 ffrenchm <ff...@gmail.com>:
>>
>> Hello,
>>
>> I noticed that many issue from ActiveMQ 5.3 has been moved to ActiveMQ
>> 5.4
>> and unscheduled. So I've the impression that ActiveMQ 5.3 will be
>> delivered
>> soon. Am I false ? Where can I find the schedule of ActiveMQ 5.3 delivery
>> ?
>>
>> I noticed that for ActiveMQ 5.2 the delivery is based on a svn TAG.
>> That's
>> mean no patch or SP delivery on this version. Will you apply the same
>> policy
>> for ActiveMQ 5.3 ?
>>
>> Finally I noticed that the issues I raised like many others has been
>> moved
>> to 'unscheduled'. My problem is that for one of these issues (AMQ-2216) I
>> provided a correction with JUNIT test and I'm currently using ActiveMQ
>> 5.3
>> with this correction. The aim of my work is to make work ActiveMQ at
>> production.
>> So I would like to get a feed back from ActiveMQ experts on this
>> correction
>> and I would like to know your point on how I'm supposed to deliver
>> ActiveMQ
>> if this correction is not scheduled on any ActiveMQ delivery ? From my
>> point
>> it seems I need to work independently on ActiveMQ source code and finally
>> deliver a forked ActiveMQ which finally means:
>>
>> + a dubious correction report from ActiveMQ trunk on my side.
>> + a fall of my motivation to provide correction and JUNIT test in order
>> to
>> help ActiveMQ community as it's not enough to get a quicker resolution on
>> my
>> issue.
>> + finally a fall of potential commiters on ActiveMQ side (in this case me
>> because 'never say never' :).
>>
>> I don't like this solution because I prefer to work with the ActiveMQ
>> community as much as possible. But as I've also delivery deadline I must
>> choose the most proper way to achieve my aim and today it's seems for me
>> the
>> most proper way is to fork ActiveMQ on my side and work independently on
>> this fork.
>>
>> Thanks for your answers
>> --
>> View this message in context:
>> http://www.nabble.com/About-ActiveMQ-5.3-and-issues-management-tp24516761p24516761.html
>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>>
>>
> 
> 
> 
> -- 
> http://blog.garytully.com
> 
> Open Source Integration
> http://fusesource.com
> 
> 

-- 
View this message in context: http://www.nabble.com/About-ActiveMQ-5.3-and-issues-management-tp24516761p24518536.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Re: About ActiveMQ 5.3 and issues management

[Gary Tully <ga...@gmail.com>]

There is no schedule as such, save that I think we should wait till
camel 2.0 is released and the outstanding (13) scheduled issues from
http://issues.apache.org/activemq/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10520&fixfor=11914
are resolved along with anything critical that pops up in the mean
time. It is very hard to put an exact time line on this, in addition,
the testing that follow a release candidate can often precipitate new
issues.

The push out of issues to 5.3.4 was the first effort to constrain the
release. I tried to retain any issue that had a patch and junit test.
Part of the intention was to solicit response, so in your case, it
looks like AMQ-2216 should be reinstated as fix for 5.3.

We welcome, appreciate and want to encourage your contribution so
apologies if it looked like it was being ignored.

2009/7/16 ffrenchm <ff...@gmail.com>:
>
> Hello,
>
> I noticed that many issue from ActiveMQ 5.3 has been moved to ActiveMQ 5.4
> and unscheduled. So I've the impression that ActiveMQ 5.3 will be delivered
> soon. Am I false ? Where can I find the schedule of ActiveMQ 5.3 delivery ?
>
> I noticed that for ActiveMQ 5.2 the delivery is based on a svn TAG. That's
> mean no patch or SP delivery on this version. Will you apply the same policy
> for ActiveMQ 5.3 ?
>
> Finally I noticed that the issues I raised like many others has been moved
> to 'unscheduled'. My problem is that for one of these issues (AMQ-2216) I
> provided a correction with JUNIT test and I'm currently using ActiveMQ 5.3
> with this correction. The aim of my work is to make work ActiveMQ at
> production.
> So I would like to get a feed back from ActiveMQ experts on this correction
> and I would like to know your point on how I'm supposed to deliver ActiveMQ
> if this correction is not scheduled on any ActiveMQ delivery ? From my point
> it seems I need to work independently on ActiveMQ source code and finally
> deliver a forked ActiveMQ which finally means:
>
> + a dubious correction report from ActiveMQ trunk on my side.
> + a fall of my motivation to provide correction and JUNIT test in order to
> help ActiveMQ community as it's not enough to get a quicker resolution on my
> issue.
> + finally a fall of potential commiters on ActiveMQ side (in this case me
> because 'never say never' :).
>
> I don't like this solution because I prefer to work with the ActiveMQ
> community as much as possible. But as I've also delivery deadline I must
> choose the most proper way to achieve my aim and today it's seems for me the
> most proper way is to fork ActiveMQ on my side and work independently on
> this fork.
>
> Thanks for your answers
> --
> View this message in context: http://www.nabble.com/About-ActiveMQ-5.3-and-issues-management-tp24516761p24516761.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>
>



-- 
http://blog.garytully.com

Open Source Integration
http://fusesource.com