On Thursday, July 07, 2011 10:40:50 AM Willem Jiang wrote: > OK, I see the patch rule is based on the Talend customer.
To be clear, I didn't say this is driven by a Talend customer. Again, they don't care if it's done here or in a private repo or something. However, if I'm doing some work for a Talend customer, it makes sense to me that everyone can benefit from it. This can be perfectly applied for Fuse as well. I know you spend a lot of time porting fixes back to 2.7.x (and 2.6.x, etc...) for Fuse customers. Other Camel users COULD benefit from that work as well. That's completely up to you guys though. Dan > > On 7/6/11 9:32 PM, Daniel Kulp wrote: > > One other note: > > > > Talend has customers on 2.7.x that are not likely to move to 2.8.0 any > > time soon. As Christian pointed out, lots of companies use a 6-8 > > month cycle, Some longer, some shorter, and won't move off what they > > have for quite a bit of time. Thus, no matter what, I am going to > > have to port some bug fixes back to 2.7.x. There isn't anyway for me > > to avoid that (unless I tell my customers "too bad, no fixes" which > > would not go over well :-) ). I COULD do the porting on some private > > fork of the Camel branches and deliver the fixes to the customers that > > way. That's definitely a perfectly valid way to do it. In that case, > > all my work really would just benefit a small number of Camel users. > > I'd MUCH MUCH prefer to do the porting here and allow my work to > > benefit the entire Camel community. It's the exact same amount of > > work, just in a different place. (well, I suppose if the fork is using > > git, it could be a little less work as merging with git is so much > > nicer and faster, but still, that's minor) > > > > Likewise for releases. I could create private releases and stick them > > in a "talend" repository someplace (and in some cases, I may need to do > > that anyway), but I could also do roughly the same amount of work here > > (calling the vote is additional work here, but that's minor) and the > > entire Camel user base benefits. In addition, the releases here would > > go to central which makes our customers happy. (no Nexus updates, > > firewall rules updates, etc...) > > > > In short, the incremental cost for *ME* to continue supporting the fixes > > branches that our customers are using is negligible. There's really no > > reason to not do it. It has an additional benefit of making other > > Camel users happier by providing more stable releases for them to use. > > IMO, it's basically a "win-win" all around, or am I missing something? > > > > Dan > > > > On Wednesday, July 06, 2011 7:55:16 AM Christian Schneider wrote: > >> Hi Willem, > >> > >> I can explain a bit from my experience as a user of Camel and CXF at > >> my > >> former employer regarding patch releases. > >> > >> We updated our stack every 6 to 8 months. With CXF this mostly simply > >> worked. When some bug was detected we could create an issue and help > >> fix > >> it. It went into the next patch release and we could > >> update to this one instead of the feature release. > >> > >> With Camel it was different. Every new release had a lot of new > >> features > >> and changes. So we almost every time found a bug in the release that > >> prevented us to switch or that was a problem in production that needed > >> to be addressed. What went very well in Camel was reporting and fixing > >> bugs. I think Camel is probably the project I used where fixes to bugs > >> were made fastest. The problem was that the fix was only on trunk. > >> Then > >> later it was incorporated into the new version. So my first strategy > >> was > >> to update to the most current camel release when a bug was found and > >> fixed. The problem was that we almost every time found another problem > >> in the new release. > >> So what I did in the end was building our own release with the patches > >> to the bugs we had. This worked very well but not every customer wants > >> to do this. > >> > >> Patch releases like 2.7.3 give the customer the fixes they need > >> without > >> the breaking changes that cause new bugs. So from a customer > >> standpoint > >> patch releases are very valueable. Of course they make life for us > >> more > >> complicated so I think we should mostly only support one patch release > >> and one feature release at the same time. Of course a company like > >> Fuse > >> or Talend can also do patch releases on their own but I think it is > >> better to have these releases at apache so it is transparent to the > >> customer what is in each release and he has no fear of vendor lock in. > >> > >> Christian > >> > >> Am 06.07.2011 04:09, schrieb Willem Jiang: > >>> Hi Hadrian, > >>> > >>> I think we are ready for the Camel 2.8.0 release. > >>> But I'm not sure why you are still planing to do the patch release > >>> for > >>> the 2.7.x as we never do this kind small patch release unless it > >>> relates to a serious security issue before. > >>> > >>> Can we just let the people move on to Camel 2.8.0 instead of > >>> confusing > >>> about what's difference between the Camel 2.8.0 and Camel 2.7.3 ? > >>> > >>> On 7/5/11 12:11 PM, Hadrian Zbarcea wrote: > >>>> Karaf 2.2.2 is now available and Willem did the upgrade. I think > >>>> we > >>>> can > >>>> get ready to start the release. Are there any other issues that > >>>> must > >>>> go > >>>> into 2.8.0? > >>>> > >>>> I would also build a 2.7.3 at the same time, there are a few fixes > >>>> and > >>>> improvements, including some around xmlsecurity. > >>>> > >>>> Thoughts? > >>>> Hadrian > >>>> > >>>> On 06/30/2011 11:07 PM, Willem Jiang wrote: > >>>>> Hi, > >>>>> > >>>>> I just applied the patch into trunk. > >>>>> > >>>>> On 7/1/11 12:36 AM, Donald Whytock wrote: > >>>>>> https://issues.apache.org/jira/browse/CAMEL-3948 > >>>>>> > >>>>>> On Thu, Jun 30, 2011 at 12:35 PM, Donald > >>>>>> Whytock<dwhyt...@gmail.com> > >>>>>> > >>>>>> wrote: > >>>>>>> Just a reminder...CAMEL-3948 is marked as fixed, but the > >>>>>>> current > >>>>>>> trunk > >>>>>>> still needs my final patch. > >>>>>>> > >>>>>>> Don > >>>>>>> > >>>>>>> On Thu, Jun 30, 2011 at 2:46 AM, Jean-Baptiste > >>>>>>> > >>>>>>> Onofré<j...@nanthrax.net> wrote: > >>>>>>>> Hi Claus, > >>>>>>>> > >>>>>>>> Regarding Karaf 2.2.2, I've released OPS4J dependencies > >>>>>>>> yesterday. > >>>>>>>> Jamie > >>>>>>>> will cut off the release this afternoon. > >>>>>>>> > >>>>>>>> Regards > >>>>>>>> JB > >>>>>>>> > >>>>>>>> On 06/30/2011 08:31 AM, Claus Ibsen wrote: > >>>>>>>>> Hi > >>>>>>>>> > >>>>>>>>> Okay the JIRA roadmap for Camel 2.8 seems good now. > >>>>>>>>> There is > >>>>>>>>> 2 open > >>>>>>>>> tickets. > >>>>>>>>> - https://issues.apache.org/jira/browse/CAMEL-3774 > >>>>>>>>> - https://issues.apache.org/jira/browse/CAMEL-4144 > >>>>>>>>> > >>>>>>>>> CAMEL-3774 is about generating the manual and is > >>>>>>>>> assigned to > >>>>>>>>> Hadrian. > >>>>>>>>> > >>>>>>>>> CAMEL-4144 is about upgrading to Karaf 2.2.2. That > >>>>>>>>> release > >>>>>>>>> is in > >>>>>>>>> progress. > >>>>>>>>> So by good chance we should be able to pickup that > >>>>>>>>> version > >>>>>>>>> when its > >>>>>>>>> released. > >>>>>>>>> Alternatively we can stick to Karaf 2.2.1 which works > >>>>>>>>> fine. > >>>>>>>>> (CAMEL-4144 is about some maven validate goal that would > >>>>>>>>> require > >>>>>>>>> Karaf > >>>>>>>>> 2.2.2 to pickup a fix in Karaf, but running Camel in > >>>>>>>>> Karaf > >>>>>>>>> is > >>>>>>>>> absolutely fine) > >>>>>>>>> > >>>>>>>>> The CI servers also seems good. Although they tend to > >>>>>>>>> run > >>>>>>>>> out of > >>>>>>>>> memory at the end, such as when testing the examples. > >>>>>>>>> But > >>>>>>>>> those are > >>>>>>>>> the last piece of the build, and thus all components > >>>>>>>>> tests > >>>>>>>>> fine. > >>>>>>>>> > >>>>>>>>> I suggest that when Karaf 2.2.2 is out we git it a few > >>>>>>>>> spins > >>>>>>>>> on > >>>>>>>>> the CI > >>>>>>>>> servers and then start cutting the Camel 2.8 release. > >>>>>>>>> Would > >>>>>>>>> be > >>>>>>>>> good to > >>>>>>>>> get it out before the summer vacation starts. As well > >>>>>>>>> its > >>>>>>>>> more > >>>>>>>>> than 3 > >>>>>>>>> months since Camel 2.7 was released. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Mon, Jun 27, 2011 at 9:35 AM, Claus > >>>>>>>>> Ibsen<claus.ib...@gmail.com> > >>>>>>>>> > >>>>>>>>> wrote: > >>>>>>>>>> Hi > >>>>>>>>>> > >>>>>>>>>> Okay we should really start focusing on getting the > >>>>>>>>>> last > >>>>>>>>>> tickets > >>>>>>>>>> which > >>>>>>>>>> has been assigned for 2.8 release done now. > >>>>>>>>>> There is about 350 tickets on the roadmap, so its > >>>>>>>>>> going to > >>>>>>>>>> be the > >>>>>>>>>> biggest release, since 2.0 went GA. > >>>>>>>>>> > >>>>>>>>>> So please take a look at your assigned tickets and get > >>>>>>>>>> them > >>>>>>>>>> done, or > >>>>>>>>>> move them for 2.9. > >>>>>>>>>> Then keep eyes on CI servers and help fix any test > >>>>>>>>>> failures, so we > >>>>>>>>>> have green builds. > >>>>>>>>>> > >>>>>>>>>> The summer vacation period is approaching so we should > >>>>>>>>>> IMHO get > >>>>>>>>>> the > >>>>>>>>>> 2.8 release out early next month if possible. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Thu, Jun 9, 2011 at 2:47 PM, Hadrian > >>>>>>>>>> Zbarcea<hzbar...@gmail.com> > >>>>>>>>>> > >>>>>>>>>> wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> I would propose starting to close down and prepare > >>>>>>>>>>> for > >>>>>>>>>>> the 2.8.0 > >>>>>>>>>>> release > >>>>>>>>>>> in > >>>>>>>>>>> 2-3 weeks. There are already 282 issues for 2.8.0 > >>>>>>>>>>> and > >>>>>>>>>>> chances are > >>>>>>>>>>> will > >>>>>>>>>>> be > >>>>>>>>>>> over 300 by the release time, probably setting a new > >>>>>>>>>>> record. > >>>>>>>>>>> > >>>>>>>>>>> As of now there are 17 issues unresolved, a few of > >>>>>>>>>>> them > >>>>>>>>>>> almost > >>>>>>>>>>> done, so > >>>>>>>>>>> by > >>>>>>>>>>> next week I assume there'll be significantly less. I > >>>>>>>>>>> would > >>>>>>>>>>> suggest > >>>>>>>>>>> shifting > >>>>>>>>>>> the focus from adding new features to stabilizing > >>>>>>>>>>> the > >>>>>>>>>>> build. If > >>>>>>>>>>> there > >>>>>>>>>>> are > >>>>>>>>>>> any issues you know of that you think absolutely > >>>>>>>>>>> must be > >>>>>>>>>>> in 2.8.0 > >>>>>>>>>>> please > >>>>>>>>>>> shout and ask for help if needed (especially non > >>>>>>>>>>> committers > >>>>>>>>>>> subscribing > >>>>>>>>>>> to > >>>>>>>>>>> this list). > >>>>>>>>>>> > >>>>>>>>>>> Thoughts? > >>>>>>>>>>> > >>>>>>>>>>> Hadrian -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
