I think in general we should only port bug fixes. Normally I would not
backport improvements as they have a higher chance of breaking code.
This said I think the backports for 2.8.2 are ok as 2.9.0 will
definately introduce some incompatibilities because of the many
refactorings I did. So the 2.8.2
is a chance to bring some features to people who do not want to upgrade
to 2.9.0 at the moment. This is a special case though as we need these
changes as a preparation for 3.0.
Christian
Am 22.09.2011 04:08, schrieb Christian Müller:
May I miss something, but at the moment it's not really clear for me WHAT
should be backported.
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...
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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
