On Thu, Sep 22, 2011 at 4:08 AM, Christian Müller <christian.muel...@gmail.com> wrote: > May I miss something, but at the moment it's not really clear for me WHAT > should be backported.
Me too. > Do we backport EVERYTHING which doesn't break existing code (not only bugs)? > Also new features and enhancements with the risk of introducing new bugs? > Only to make it clear for me and may others... I would not favor that as new code may introduce new bugs and other side effects. I would rather allow people to have a stable branch where bug fixes is the primary reason for backporting. There may be good reasons to backport a non-bug ticket, but then we ought to be more careful when doing this. For example I think the Karaf team discuss this on @dev which tickets to backport. > > And by> 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 >> > -- 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/
