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
