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.
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 >>
