camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Davies <rajdav...@gmail.com>
Subject Re: Camel 2.8.2 - Reason for the many backports?
Date Wed, 21 Sep 2011 17:34:13 GMT
Awesome! - thanks Dan
On 21 Sep 2011, at 15:23, Daniel Kulp wrote:

> On Wednesday, September 21, 2011 2:53:49 PM Rob Davies wrote:
>> For my part it is the principle - at some point this will go wrong - doing
>> what Chistian suggested makes a lot of sense. And, users in production want
>> stability, fixes are good, new features leads naturally to concern about
>> stability. It should be good practice to give a heads up at least, before
>> backporting new features.
> 
> I agree that I should have given a better "hey, ton of stuff going to happen" 
> heads up Monday morning (or Friday).   
> 
> That said, I had complete intention after 2.8.0 was released to try and port 
> things back more on a weekly basis or so.   That makes things a LOT easier to 
> do.   Reviewing 380+ commits in one day is really not fun.  :-)     I've just 
> been quite a bit busy on other things that the Camel porting kept falling off 
> the bottom of my weekly todo list.    :-(
> 
> Going forward, I'm hoping to keep being able to port fixes and such back on a 
> semi-weekly basis (+/- a little bit) much like I do for CXF.    Obviously, any 
> help from anyone else would be greatly appreciated.   In CXF, over time, I've 
> gotten more help from Sergey and Willem and Freeman and others and I greatly 
> appreciate their efforts.   I've seen Claus and Jon and others pulling things 
> back here as well which is definitely appreciated.
> 
> 
> Dan
> 
> 
>> On 21 Sep 2011, at 14:33, Hadrian Zbarcea wrote:
>>> This is an emotional non-discussion. The question in the title is what
>>> is the reason for the *many* backports. An explanation was also given:
>>> if they are *many* bugs (or improvements), they should be fixed, and in
>>> dkulp's opinion not only on the trunk but also on the maintained
>>> branches. There is also an expectation for the fixes to be backwards
>>> compatible, which is absolutely normal. From what I see the expectation
>>> was fulfilled.
>>> 
>>> Rob seems to imply that he trusts Dan to do the right thing, but he's
>>> concerned about the precedent he sets for the less talented rest of us
>>> who might go wild and break things.
>>> 
>>> Did I get it right? Is there a particular commit that triggered this
>>> question, or is more the principle?
>>> 
>>> Hadrian
>>> 
>>> On 09/21/2011 01:36 AM, Rob Davies wrote:
>>>> Dan it admirable what you want to do but it would be better to
>>>> encourage collective best practice - so we do not break backward
>>>> compatibility on a released branch. That's why discussing adding new
>>>> features, or changes to dependencies on the DEV list first is a good
>>>> idea. it will set the pattern that others will follow. Its not that
>>>> we expect that you will break anything, but others might do by
>>>> accident.>> 
>>>> On 21 Sep 2011, at 04:08, Daniel Kulp wrote:
>>>>> On Tuesday, September 20, 2011 7:20:20 PM Claus Ibsen wrote:
>>>>>> Hi Dan
>>>>>> 
>>>>>> Do you care to discuss this?
>>>>>> 
>>>>>> You keep on backporting non bug fixes, new features and whatnot.
>>>>>> 
>>>>>> People who run Camel in production and they may want to upgrade to
>>>>>> 2.8.2 due to a bug.
>>>>>> They frankly do not like a lot of changes. As any change in a
>>>>>> production system is not desireable.
>>>>> 
>>>>> And there are even more people that are trying to move their
>>>>> applications from development into testing or production and cannot
>>>>> because they are hitting specific bugs or require some trivial
>>>>> features or issues to be resolved.
>>>>> 
>>>>> If a user reports a bug (and even better, provides a patch), we
>>>>> definitely owe it to them to get that fix pulled back relatively
>>>>> quickly.   Camel has historically done a VERY poor job of doing
>>>>> that.  I keep talking to people that have either had to fork Camel
>>>>> internally to get patches applied or go to a third party to demand
>>>>> various things ported back.     In both cases, I just cringe as
>>>>> that shows that we, as a community, have failed our users.
>>>>> 
>>>>> Likewise, if a user needs a trivial change in order to get Camel
>>>>> into
>>>>> production, we should try and get that change to them WITHOUT a huge
>>>>> upgrade hassle.   Things like new methods, new config options (as
>>>>> long as the defaults remain as before), etc...  that would have no
>>>>> impact on existing users, but makes it possible to use Camel by a
>>>>> wider audience.
>>>>> 
>>>>>> So the gap from 2.8.0, 2.8.1 to 2.8.2 is now very big. This is not
>>>>>> desireable.
>>>>> 
>>>>> Compared to any CXF patch release, it's about average at this point.
>>>>> 
>>>>>> On Tue, Sep 20, 2011 at 8:11 AM, Claus Ibsen<claus.ibsen@gmail.com>
 
> wrote:
>>>>>>> Hi
>>>>>>> 
>>>>>>> Dan what is the reason why you backport so many commits to 2.8.2
>>>>>>> from
>>>>>>> 2.9?
>>>>>>> 
>>>>>>> The "problem" is that its a lot of new features, non trivial
bug
>>>>>>> fixes and whatnot.
>>>>>>> People then may not have a safe upgrade from 2.8.0 / 2.8.1 to
>>>>>>> 2.8.2
>>>>>>> because of the "big difference".
>>>>>>> People is more prepared for a little trouble when doing 2.8.0
to
>>>>>>> 2.9.0 upgrade. But not for an upgrade in 2.8.x branch.
>>>>>>> 
>>>>>>> Also for new features and whatnot we update the documentation
to
>>>>>>> indicate eg *Camel 2.9* that
>>>>>>> this is a new feature in that version. These documentation
>>>>>>> changes is
>>>>>>> not part of the SVN and thus
>>>>>>> you lose this, and cannot keep the documentation<->  source
code
>>>>>>> in
>>>>>>> sync.
>>>>> 
>>>>> Yea.  Docs are definitely an issue.   I'll admit that.   They don't
>>>>> really end up "wrong",  but  not 100% correct either.   :-)      If
>>>>> you consider a feature not "complete" until documented, and it's
>>>>> not documented until 2.9, then the docs are correct if they say
>>>>> 2.9.    Yea, kind of a silly answer. Fixing the docs should
>>>>> definitely be done as well.   I'll try and look a little at that in
>>>>> the next couple days.   (and thanks Jon for the help!)
>>>>> 
>>>>> In anycase, I'm trying to provide a usable solution for our users.  
>>>>> This processed has worked extremely well based on past experience. 
>>>>> If there is a particular commit that I merged back that you are
>>>>> particularly concerned about, feel free to bring it up.  We can
>>>>> work on finding a solution that would solve the problem in a way
>>>>> with less impact on the users.
>>>>> 
>>>>> Dan
>>>>> 
>>>>>>> --
>>>>>>> Claus Ibsen
>>>>>>> -----------------
>>>>>>> FuseSource
>>>>>>> Email: cibsen@fusesource.com
>>>>>>> Web: http://fusesource.com
>>>>>>> Twitter: davsclaus, fusenews
>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>> 
>>>>> --
>>>>> Daniel Kulp
>>>>> dkulp@apache.org
>>>>> http://dankulp.com/blog
>>>>> Talend - http://www.talend.com
> -- 
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com


Mime
View raw message