Re: Camel 2.8.2 - Reason for the many backports?

[Hadrian Zbarcea]

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