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.ib...@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: cib...@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
>>>>> dk...@apache.org
>>>>> http://dankulp.com/blog
>>>>> Talend - http://www.talend.com
> --
> Daniel Kulp
> dk...@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
