camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Camel 2.8.2 - Reason for the many backports?
Date Sun, 25 Sep 2011 15:19:37 GMT
On Sat, Sep 24, 2011 at 7:34 PM, Christian Müller
<> wrote:
> Hello Claus!
> Thank you for your work updating the WIKI page. I didn't know them...

Yeah there is some good to know wiki pages for Camel team members here

> But I have to "stress" this topic a bit more, because I still have open
> questions:
> 1) Is it a problem when different committers use different merge tools (the
> Java program, the Python script, simply Git, ...)?

Dan already explained. For windows users you may use cygwin or some
unix emulator to be able to run the python script.
Or maybe adjust the source code in and have it invoked
the windows .exe port of the

> 2) What is our policy about backporting issues (only bugs, dependency
> upgrades for bug fix versions, improvements, new features, dependency
> upgrades which are not bug fix versions, ...)?

It ought to be bug fixes only, with zero dependency upgrades. However
there could be just cause to upgrade
a dependency due to a security fix, or very important bug fixes in a dependency.
For example Apache CXF has many bugs in recent releases which gets fixed.
(eg CXF 2.4.2 have 59 bug fixes -

At Apache Camel we did that for Camel 2.8.1 release.
However the current state of 2.8.2 is unfortunately not following that practice.

There seems to be backported *too* many commits.
For example the state of 2.8.2, even include commits which was
*deliberately* omitted for the 2.8.1. Granted the should
possible have some of those tickets set as "blocked". But the commits
was done without any prior heads-up. The offset ought to have started
from 2.8.1 release and then the changes since. But the offset was
started from the Camel 2.8.0 release, and thus includes commits which
we * deliberately* omitted in Camel 2.8.1.

The Karaf team seems to have a better practice, by discussing on the
@dev which tickets to backport (especially if non-bug tickets).
We the Camel team ought to follow their example IMHO, and also discuss
which tickets to backport.
Especially for non-bug tickets.

Likewise I don't believe there is one uber-person (that would include
me as that uber-person, in case you wonder)
who should sit and backport a batch of commits. Its the duty of all of
us to backport tickets.
In fact I think its primary the persons who actually worked on the
tickets, at the given time, is the
best person to judge if the ticket is "safe" to backport. But having a
weekly/semi-weekly procedure of discussing
and backport any "left overs" is a good idea. Then we ensure that the
maintenance branches is not becoming doormat
and we have a repeatable procedure in place, that the community can
rely upon. And they over time get familiar with.
If they keep an eye on the commit logs / JIRA - they see the progress
and that tickets get backport in timely manner.
There are possible a rare number of people who may even try out
SNAPSHOT versions of maintenance branches.
So it would help if tickets is back ported on a regularly basis.

We may also consider adding some note/field in JIRA if a ticket is
"not safe" to backport. Sometimes you work on a bug/improvement
that is just too complicated/or too big/risk of introducing side
effects/or rely upon other improvements/new features etc. that its not
feasible to backport. For example if we have a known work-around it
could be better to notice the workaround in the release notes for that
given release.

> 3) Still not clear why we backport many issues to 2.8.2 and not to 2.7.4.
> I stess this to make it clear for everybody, document it and to provide a
> better mentoring for new committers.
> Christian
> Sent from a mobile device

Claus Ibsen
Twitter: davsclaus, fusenews
Author of Camel in Action:

View raw message