You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2011/09/20 08:11:57 UTC
Camel 2.8.2 - Reason for the many backports?
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.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Daniel Kulp <dk...@apache.org>.
On Saturday, September 24, 2011 7:34:14 PM Christian Müller wrote:
> Hello Claus!
>
> Thank you for your work updating the WIKI page. I didn't know them...
>
> 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, ...)?
the Java program just calls out to the python script so those are one in the
same. The java program also has a "Record" option for the git case that
will record that a merge was made without actually attempting the merge.
Colm does this to me all the time in CXF. He uses git to cherry-pick merges.
I just need to keep an eye on what he does and when I run DoMerges, I just
"[R]ecord" his changes instead of merging them.
> 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, ...)?
I agree with Hadrians response. Nothing really to add.
> 3) Still not clear why we backport many issues to 2.8.2 and not to 2.7.4.
Time. Any help appreciated. :-)
Dan
>
> 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
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Sep 27, 2011 at 7:18 PM, Christian Müller
<ch...@gmail.com> wrote:
> I updated [Merging commits from trunk to fixes branch|
> https://cwiki.apache.org/confluence/display/CAMEL/Merging+commits+from+trunk+to+fixes+branch]
> with the information how to merge with git/git-svn.
>
> At present, I think we do not have a consensus at all, what should be merged
> into the maintenance branches.
>
> I think we have a consensus to merge/back port the following issues:
> - issues considered as bug
> - dependency updates on the micro version number (e.g. from 1.0.0 to 1.0.1)
>
> I also think we have a consensus to NOT merge/back port the following
> issues:
> - any change which changes the Camel API
> - any change which changes the behavior for the user (other default value,
> ...)
>
> On the following cases, we have different opinions:
> - dependency updates on the major version number (e.g. from 1.0.0 to 2.0.0)
> - dependency updates on the minor version number (e.g. from 1.0.0 to 1.1.0)
> - improvements which NOT changes the API or the behavior (fully backwards
> compatible)
> - new features which NOT changes the API or the behavior (fully backwards
> compatible)
>
Nice lay out of the items in the bullets above.
I am a bit torn in terms of dependency updates, as some ppl may want
this, and others want no updates.
I can understand a dependency update on the patch level / or even a
minor update if there is a justification
that it fixes some major issues that the end users suffer.
> I prefer only to back port issues where we already have a consensus. The
> reason is simply code stability. Each new feature, improvement or dependency
> update has the risk to introduce a new issue and break the existing code. I
> could imagine most of the users think in the same way and accept to update
> to a new major/minor release for improvements or new features. In the rare
> cases where this is not the case, there are commercial vendors which could
> fill this gap...
> But why we don't ask our users and let they decide? I would like to start a
> public [VOTE] on user@ for one week or so and ask our users what they
> prefer. What do you think?
>
That can be a good idea, but the people who speak in the Apache
mailing lists, is only
the tip of the iceberg of all our end users. And one week is not a
very long time.
I think an easier way of submitting your comment would be some sort of
survey in a web form
where you do not need to sign up for a mailing list etc. Maybe we
could do a 2nd survey
and have questions in relationship to this in the survey, (along with
some other questions as well).
> Another "issue" is how to document the availability of new features without
> confusing our users. e.g. "from Camel 2.7.4 but not in 2.8.0 and 2.8.1"?
>
Yep when the documentation is part of the source code in the SVN, then
we can have this resolved.
> Looking forward of your comments,
> Christian
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Christian Müller <ch...@gmail.com>.
I updated [Merging commits from trunk to fixes branch|
https://cwiki.apache.org/confluence/display/CAMEL/Merging+commits+from+trunk+to+fixes+branch]
with the information how to merge with git/git-svn.
At present, I think we do not have a consensus at all, what should be merged
into the maintenance branches.
I think we have a consensus to merge/back port the following issues:
- issues considered as bug
- dependency updates on the micro version number (e.g. from 1.0.0 to 1.0.1)
I also think we have a consensus to NOT merge/back port the following
issues:
- any change which changes the Camel API
- any change which changes the behavior for the user (other default value,
...)
On the following cases, we have different opinions:
- dependency updates on the major version number (e.g. from 1.0.0 to 2.0.0)
- dependency updates on the minor version number (e.g. from 1.0.0 to 1.1.0)
- improvements which NOT changes the API or the behavior (fully backwards
compatible)
- new features which NOT changes the API or the behavior (fully backwards
compatible)
I prefer only to back port issues where we already have a consensus. The
reason is simply code stability. Each new feature, improvement or dependency
update has the risk to introduce a new issue and break the existing code. I
could imagine most of the users think in the same way and accept to update
to a new major/minor release for improvements or new features. In the rare
cases where this is not the case, there are commercial vendors which could
fill this gap...
But why we don't ask our users and let they decide? I would like to start a
public [VOTE] on user@ for one week or so and ask our users what they
prefer. What do you think?
Another "issue" is how to document the availability of new features without
confusing our users. e.g. "from Camel 2.7.4 but not in 2.8.0 and 2.8.1"?
Looking forward of your comments,
Christian
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Christian Müller <ch...@gmail.com>.
I also think the best is, the assignee/owner of an issue is responsible for
backporting it to the maintenance branches. He knows best, whether or not
the issue can be backported or not. It can also make sure the WIKI pages are
up to date.
I will pick some easy issues and try the possible ways to backport the
fixes. I will also describe the way how to merge with git-svn.
Best,
Christian
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Willem Jiang <wi...@gmail.com>.
Hi Claus,
I just ran the "svnmerge.py merge -r1175323" to merge the patch by hand,
but after checking the commit mail, I found I forget to update the
svnmerge-commit-message.txt with the original commit log :(
On 9/25/11 11:29 PM, Claus Ibsen wrote:
> On Fri, Sep 23, 2011 at 3:09 PM, Willem Jiang<wi...@gmail.com> wrote:
>> Hi Claus,
>>
>> I just found your svnmerge.py doesn't has the detail log message like this,
>> it may be cause by your old copy of svnmerge.py.
>>
>> Author: davsclaus
>> Date: Fri Sep 23 07:51:41 2011
>> New Revision: 1174573
>>
>> URL: http://svn.apache.org/viewvc?rev=1174573&view=rev
>> Log:
>> Merged revisions 1174571 via svnmerge from
>> https://svn.apache.org/repos/asf/camel/branches/camel-2.8.x
>>
>> *< we should get some commit message here>*
>>
>
> Thanks Willem.
>
> I think that old svmerge.py file may have an issue. I have switched to
> use the copy from Dan.
> I had trouble today backporting a fix to the 2.7 branch.
> Could anyone try to backport CAMEL-4487? The rev number in the 2.8
> branch is: 1175323
>
> CAMEL-4487 is a low-risk, minor bug fix, that would be safe to
> backport to the 2.7 branch.
>
>
>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Sep 23, 2011 at 3:09 PM, Willem Jiang <wi...@gmail.com> wrote:
> Hi Claus,
>
> I just found your svnmerge.py doesn't has the detail log message like this,
> it may be cause by your old copy of svnmerge.py.
>
> Author: davsclaus
> Date: Fri Sep 23 07:51:41 2011
> New Revision: 1174573
>
> URL: http://svn.apache.org/viewvc?rev=1174573&view=rev
> Log:
> Merged revisions 1174571 via svnmerge from
> https://svn.apache.org/repos/asf/camel/branches/camel-2.8.x
>
> *< we should get some commit message here >*
>
Thanks Willem.
I think that old svmerge.py file may have an issue. I have switched to
use the copy from Dan.
I had trouble today backporting a fix to the 2.7 branch.
Could anyone try to backport CAMEL-4487? The rev number in the 2.8
branch is: 1175323
CAMEL-4487 is a low-risk, minor bug fix, that would be safe to
backport to the 2.7 branch.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Sep 24, 2011 at 8:32 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> Excellent points Christian. My take on this inline.
>
> Hadrian
>
> On 09/24/2011 01:34 PM, Christian Müller wrote:
>>
>> Hello Claus!
>>
>> Thank you for your work updating the WIKI page. I didn't know them...
>>
>> 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, ...)?
>
> Probably not. The result it what matters. As long as the tool does the job
> everybody should use what he's comfortable with, unless there is a very good
> reason not to (don't see one in this case).
>
>> 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, ...)?
>
> I think we should backport as much as possible and give our users the best
> experience possible on any supported branch as long as:
We have to agree if its a *patch* release or if its not a patch release.
A patch release is supposed to be a 100% drop-in replacement to fix
some major bugs / security vulnerabilities.
A very low-risk upgrade, with just enough changes, and nothing more.
Better to be conservative and omit a commit, than to include it, if
you are in doubt.
> * we have 100% backward compatibility on patch versions (3rd digit).
We do not have that for 2.8.2. There is API changes. There is new
features backported, which risk introducing new bugs.
There is problem keeping documentation up to date, when backporting
new features, as you would have to remember
to update the documentation as well. Which wasn't the case for 2.8.2.
This will of course get better if the documentation was part
of the SVN.
> Dependencies versions may be upgraded to include fixed bugs, but probably
> not to a major release
> * almost 100% compatibility on minor releases. Simple, straightforward
> migration steps if at all.
>
And this is *certainly* not the case for Camel 2.9. But we are already
debating this in another thread.
>> 3) Still not clear why we backport many issues to 2.8.2 and not to 2.7.4.
>
> We should backport as much as we can to 2.7.x while it is maintained. I
> think it's just a matter of finding the time to do it.
>
>
>> I stess this to make it clear for everybody, document it and to provide a
>> better mentoring for new committers.
>
> Yes, by all means we should document that. It'll be helpful to both
> committers and users at large who would know what to expect.
>
>
>>
>> Christian
>>
>> Sent from a mobile device
>>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Excellent points Christian. My take on this inline.
Hadrian
On 09/24/2011 01:34 PM, Christian Müller wrote:
> Hello Claus!
>
> Thank you for your work updating the WIKI page. I didn't know them...
>
> 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, ...)?
Probably not. The result it what matters. As long as the tool does the
job everybody should use what he's comfortable with, unless there is a
very good reason not to (don't see one in this case).
> 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, ...)?
I think we should backport as much as possible and give our users the
best experience possible on any supported branch as long as:
* we have 100% backward compatibility on patch versions (3rd digit).
Dependencies versions may be upgraded to include fixed bugs, but
probably not to a major release
* almost 100% compatibility on minor releases. Simple, straightforward
migration steps if at all.
> 3) Still not clear why we backport many issues to 2.8.2 and not to 2.7.4.
We should backport as much as we can to 2.7.x while it is maintained. I
think it's just a matter of finding the time to do it.
> I stess this to make it clear for everybody, document it and to provide a
> better mentoring for new committers.
Yes, by all means we should document that. It'll be helpful to both
committers and users at large who would know what to expect.
>
> Christian
>
> Sent from a mobile device
>
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Sep 24, 2011 at 7:34 PM, Christian Müller
<ch...@gmail.com> 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
http://camel.apache.org/developers.html
> 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 DoMerges.java and have it invoked
the windows .exe port of the svnmerge.py.
> 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 -
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+CXF+AND+fixVersion+%3D+%222.4.2%22+ORDER+BY+issuetype+ASC%2C+key+DESC)
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 svnmerge.py 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
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Christian Müller <ch...@gmail.com>.
Hello Claus!
Thank you for your work updating the WIKI page. I didn't know them...
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, ...)?
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, ...)?
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
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Willem Jiang <wi...@gmail.com>.
Hi Claus,
I just found your svnmerge.py doesn't has the detail log message like
this, it may be cause by your old copy of svnmerge.py.
Author: davsclaus
Date: Fri Sep 23 07:51:41 2011
New Revision: 1174573
URL: http://svn.apache.org/viewvc?rev=1174573&view=rev
Log:
Merged revisions 1174571 via svnmerge from
https://svn.apache.org/repos/asf/camel/branches/camel-2.8.x
*< we should get some commit message here >*
On 9/23/11 8:34 PM, Claus Ibsen wrote:
> Hi
>
> I managed to find an old copy of the svnmerge.py that works.
> However its about 20kb smaller than the latest from the trunk. And the
> file from Dan Kulp.
> 69987 Sep 23 14:16 svnmerge.py
> 90590 Sep 23 14:12 svnmerge.py.dkulp
>
> I have attached the file that works on my mac laptop.
>
> I also set my LANG to UTF-8 as follows
> export LANG=en_US.UTF-8
> export LC_ALL=en_US.UTF-8
>
> That didn't work with the latest svnmerge.py files.
> So the old file attached may work without these LANG changes.
>
> Dan pointed to me from this link
> http://groups.google.com/group/spyderlib/browse_thread/thread/299e11c6e677b277
>
>
>
>
>
> On Thu, Sep 22, 2011 at 7:02 PM, Daniel Kulp<dk...@apache.org> wrote:
>> On Thursday, September 22, 2011 6:44:42 PM Claus Ibsen wrote:
>>> Hi
>>>
>>> I gave the DoMerges tool a try and it worked fine.
>>>
>>> However as my svnmerge.py python script causes some UTF-8 error after
>>> the merge is done, the DoMerges tool breaks
>>> after one merge.
>>>
>>> I tried downloading the latest svnerge.py file from the official
>>> source but it fails as well.
>>> I guess I need to find an older svnmerge.py file that dont fail at the end.
>>>
>>> If anyone got a .py file working, then feel free to attach on a mail
>>> and send to me, or this @dev.
>>
>>
>> I've attached mine. What kind of error were you getting? Does it fail
>> outside the tool as well?
>>
>> What is your LANG env variable set to?
>>
>>
>> Dan
>>
>>
>>
>>
>>
>>>
>>> On Thu, Sep 22, 2011 at 3:34 PM, Daniel Kulp<dk...@apache.org> wrote:
>>>> On Thursday, September 22, 2011 7:45:28 AM Claus Ibsen wrote:
>>>>> On Wed, Sep 21, 2011 at 4:23 PM, Daniel Kulp<dk...@apache.org> wrote:
>>>>>> I agree that I should have given a better "hey, ton of stuff going
>>>>>> to
>>>>>> happen" heads up Monday morning (or Friday).
>>>>>
>>>>> Thanks. We are not accustomed to see 70-100 backports on the 2.x
>>>>> branch overnight.
>>>>> So we were wonder what happened. If some auto tool have been enabled
>>>>> or
>>>>> whatnot?
>>>>
>>>> I really hate to point this out as it's a bit of an embarrassment to me,
>>>> but since you mentioned it.......
>>>>
>>>> If you look in:
>>>> http://svn.apache.org/repos/asf/cxf/trunk/bin/
>>>>
>>>> there is a DoMerges.java file in there that you can compile and run from
>>>> a fixes branch checkout.. It pretty much walks you through the
>>>> entire process of backporting fixes. It lists all the outstanding
>>>> commits that haven't been reviewed, allows you to [M]erge commits
>>>> individually, [B]lock commits (reviewed and shouldn't be merged back),
>>>> show the diffs, etc..... Glen added some good comment to the top of
>>>> it a couple weeks ago. For the most part, it's quite easy to walk
>>>> through a bunch of commits and merge things back with it. Takes very
>>>> little time. (one enhancement I plan to add is to have it print the
>>>> URL to the viewvc for the commit and the full URL to the JIRA if there
>>>> is one mentioned. Little easier than the pure diffs.) In anycase,
>>>> while not a complete "auto tool" that was used, it isn't hard to go
>>>> through a lot of commits.
>>>>
>>>> Why is it embarrassing to me? Well, it's a silly little Java program
>>>> that is doing the job of something SHOULD have been written in python
>>>> or perl or even bash. I'll readily admit that. Best tool for the
>>>> job was definitely not applied here.
>>>>
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org
>>>> http://dankulp.com/blog
>>>> Talend - http://www.talend.com
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>> Talend - http://www.talend.com
>
>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I managed to find an old copy of the svnmerge.py that works.
However its about 20kb smaller than the latest from the trunk. And the
file from Dan Kulp.
69987 Sep 23 14:16 svnmerge.py
90590 Sep 23 14:12 svnmerge.py.dkulp
I have attached the file that works on my mac laptop.
I also set my LANG to UTF-8 as follows
export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8
That didn't work with the latest svnmerge.py files.
So the old file attached may work without these LANG changes.
Dan pointed to me from this link
http://groups.google.com/group/spyderlib/browse_thread/thread/299e11c6e677b277
On Thu, Sep 22, 2011 at 7:02 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Thursday, September 22, 2011 6:44:42 PM Claus Ibsen wrote:
>> Hi
>>
>> I gave the DoMerges tool a try and it worked fine.
>>
>> However as my svnmerge.py python script causes some UTF-8 error after
>> the merge is done, the DoMerges tool breaks
>> after one merge.
>>
>> I tried downloading the latest svnerge.py file from the official
>> source but it fails as well.
>> I guess I need to find an older svnmerge.py file that dont fail at the end.
>>
>> If anyone got a .py file working, then feel free to attach on a mail
>> and send to me, or this @dev.
>
>
> I've attached mine. What kind of error were you getting? Does it fail
> outside the tool as well?
>
> What is your LANG env variable set to?
>
>
> Dan
>
>
>
>
>
>>
>> On Thu, Sep 22, 2011 at 3:34 PM, Daniel Kulp <dk...@apache.org> wrote:
>> > On Thursday, September 22, 2011 7:45:28 AM Claus Ibsen wrote:
>> >> On Wed, Sep 21, 2011 at 4:23 PM, Daniel Kulp <dk...@apache.org> wrote:
>> >> > I agree that I should have given a better "hey, ton of stuff going
>> >> > to
>> >> > happen" heads up Monday morning (or Friday).
>> >>
>> >> Thanks. We are not accustomed to see 70-100 backports on the 2.x
>> >> branch overnight.
>> >> So we were wonder what happened. If some auto tool have been enabled
>> >> or
>> >> whatnot?
>> >
>> > I really hate to point this out as it's a bit of an embarrassment to me,
>> > but since you mentioned it.......
>> >
>> > If you look in:
>> > http://svn.apache.org/repos/asf/cxf/trunk/bin/
>> >
>> > there is a DoMerges.java file in there that you can compile and run from
>> > a fixes branch checkout.. It pretty much walks you through the
>> > entire process of backporting fixes. It lists all the outstanding
>> > commits that haven't been reviewed, allows you to [M]erge commits
>> > individually, [B]lock commits (reviewed and shouldn't be merged back),
>> > show the diffs, etc..... Glen added some good comment to the top of
>> > it a couple weeks ago. For the most part, it's quite easy to walk
>> > through a bunch of commits and merge things back with it. Takes very
>> > little time. (one enhancement I plan to add is to have it print the
>> > URL to the viewvc for the commit and the full URL to the JIRA if there
>> > is one mentioned. Little easier than the pure diffs.) In anycase,
>> > while not a complete "auto tool" that was used, it isn't hard to go
>> > through a lot of commits.
>> >
>> > Why is it embarrassing to me? Well, it's a silly little Java program
>> > that is doing the job of something SHOULD have been written in python
>> > or perl or even bash. I'll readily admit that. Best tool for the
>> > job was definitely not applied here.
>> >
>> >
>> > --
>> > Daniel Kulp
>> > dkulp@apache.org
>> > http://dankulp.com/blog
>> > Talend - http://www.talend.com
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Claus Ibsen <cl...@gmail.com>.
>> Also how to do it with the mentioned Java/Python scripts, as we have it done
>> with our release step-by-step guide. I didn't know these scripts and nobody
>> told me about their existence. I was not able to find a WIKI page about it
>> (with my mobile phone ;-) ). I could imagine, I'm not the only one...
>>
>
> Yeah now that I got the tooling on my laptop working I would like to
> add some notes in our wiki
> how to do this.
>
> Its going to be added somewhere here, as a sub page:
> http://camel.apache.org/developers.html
>
> There should also be a .exe of the svnmerge so its easy for windows
> users to run it.
We already had a wiki page, so I have improved it. And added notes
about the DoMerges tool
https://cwiki.apache.org/confluence/display/CAMEL/Merging+commits+from+trunk+to+fixes+branch
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Sep 23, 2011 at 1:26 AM, Christian Müller
<ch...@gmail.com> wrote:
> See my notes inline
>
> Christian
> Am 22.09.2011 13:43 schrieb "Christian Müller" <christian.mueller@gmail.com
>>:
>>
>> Now it's a bit more clearer, but not totally.
>>
>> IMO, we only backported bugs and dependency changes which are bugfix
> versions in the past. With Camel 2.8.2, we backported much more - mostly
> all. I've expected a [DISCUSS] about this - not only a [HEADS UP]. I'm sure
> Dan has good reasons for this, but it shoud be discussed first.
>>
>> We backported mostly all changes (which doesn't break users existing code)
> into the 2.8 branch, but only a few changes into the 2.7 branch. Why? As
> Hadrian mentioned in the board report, the 2.7 branch is still in
> maintenance.
>>
>> When I'm back, I will add a WIKI page which describes our development
> process/policy for backporting changes.
>
> Also how to do it with the mentioned Java/Python scripts, as we have it done
> with our release step-by-step guide. I didn't know these scripts and nobody
> told me about their existence. I was not able to find a WIKI page about it
> (with my mobile phone ;-) ). I could imagine, I'm not the only one...
>
Yeah now that I got the tooling on my laptop working I would like to
add some notes in our wiki
how to do this.
Its going to be added somewhere here, as a sub page:
http://camel.apache.org/developers.html
There should also be a .exe of the svnmerge so its easy for windows
users to run it.
>> Thanks in advance for clarification,
>> Christian
>>
>> Sent from a mobile device
>>
>> Am 22.09.2011 10:12 schrieb "Guillaume Nodet" <gn...@gmail.com>:
>>
>> > Fwiw, git-svn could be handy too ... as merges are really easy with git.
>> >
>> > On Thu, Sep 22, 2011 at 19:02, Daniel Kulp <dk...@apache.org> wrote:
>> >
>> >> On Thursday, September 22, 2011 6:44:42 PM Claus Ibsen wrote:
>> >> > Hi
>> >> >
>> >> > I gave the DoMerges tool a try and it worked fine.
>> >> >
>> >> > However as my svnmerge.py python script causes some UTF-8 error after
>> >> > the merge is done, the DoMerges tool breaks
>> >> > after one merge.
>> >> >
>> >> > I tried downloading the latest svnerge.py file from the official
>> >> > source but it fails as well.
>> >> > I guess I need to find an older svnmerge.py file that dont fail at
> the
>> >> end.
>> >> >
>> >> > If anyone got a .py file working, then feel free to attach on a mail
>> >> > and send to me, or this @dev.
>> >>
>> >>
>> >> I've attached mine. What kind of error were you getting? Does it fail
>> >> outside the tool as well?
>> >>
>> >> What is your LANG env variable set to?
>> >>
>> >>
>> >> Dan
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> >
>> >> > On Thu, Sep 22, 2011 at 3:34 PM, Daniel Kulp <dk...@apache.org>
> wrote:
>> >> > > On Thursday, September 22, 2011 7:45:28 AM Claus Ibsen wrote:
>> >> > >> On Wed, Sep 21, 2011 at 4:23 PM, Daniel Kulp <dk...@apache.org>
>> >> wrote:
>> >> > >> > I agree that I should have given a better "hey, ton of stuff
> going
>> >> > >> > to
>> >> > >> > happen" heads up Monday morning (or Friday).
>> >> > >>
>> >> > >> Thanks. We are not accustomed to see 70-100 backports on the 2.x
>> >> > >> branch overnight.
>> >> > >> So we were wonder what happened. If some auto tool have been
> enabled
>> >> > >> or
>> >> > >> whatnot?
>> >> > >
>> >> > > I really hate to point this out as it's a bit of an embarrassment
> to
>> >> me,
>> >> > > but since you mentioned it.......
>> >> > >
>> >> > > If you look in:
>> >> > > http://svn.apache.org/repos/asf/cxf/trunk/bin/
>> >> > >
>> >> > > there is a DoMerges.java file in there that you can compile and run
>> >> from
>> >> > > a fixes branch checkout.. It pretty much walks you through the
>> >> > > entire process of backporting fixes. It lists all the outstanding
>> >> > > commits that haven't been reviewed, allows you to [M]erge commits
>> >> > > individually, [B]lock commits (reviewed and shouldn't be merged
> back),
>> >> > > show the diffs, etc..... Glen added some good comment to the top of
>> >> > > it a couple weeks ago. For the most part, it's quite easy to walk
>> >> > > through a bunch of commits and merge things back with it. Takes
> very
>> >> > > little time. (one enhancement I plan to add is to have it print the
>> >> > > URL to the viewvc for the commit and the full URL to the JIRA if
> there
>> >> > > is one mentioned. Little easier than the pure diffs.) In anycase,
>> >> > > while not a complete "auto tool" that was used, it isn't hard to go
>> >> > > through a lot of commits.
>> >> > >
>> >> > > Why is it embarrassing to me? Well, it's a silly little Java
> program
>> >> > > that is doing the job of something SHOULD have been written in
> python
>> >> > > or perl or even bash. I'll readily admit that. Best tool for the
>> >> > > job was definitely not applied here.
>> >> > >
>> >> > >
>> >> > > --
>> >> > > Daniel Kulp
>> >> > > dkulp@apache.org
>> >> > > http://dankulp.com/blog
>> >> > > Talend - http://www.talend.com
>> >> --
>> >> Daniel Kulp
>> >> dkulp@apache.org
>> >> http://dankulp.com/blog
>> >> Talend - http://www.talend.com
>> >>
>> >
>> >
>> >
>> > --
>> > ------------------------
>> > Guillaume Nodet
>> > ------------------------
>> > Blog: http://gnodet.blogspot.com/
>> > ------------------------
>> > Open Source SOA
>> > http://fusesource.com
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Christian Müller <ch...@gmail.com>.
See my notes inline
Christian
Am 22.09.2011 13:43 schrieb "Christian Müller" <christian.mueller@gmail.com
>:
>
> Now it's a bit more clearer, but not totally.
>
> IMO, we only backported bugs and dependency changes which are bugfix
versions in the past. With Camel 2.8.2, we backported much more - mostly
all. I've expected a [DISCUSS] about this - not only a [HEADS UP]. I'm sure
Dan has good reasons for this, but it shoud be discussed first.
>
> We backported mostly all changes (which doesn't break users existing code)
into the 2.8 branch, but only a few changes into the 2.7 branch. Why? As
Hadrian mentioned in the board report, the 2.7 branch is still in
maintenance.
>
> When I'm back, I will add a WIKI page which describes our development
process/policy for backporting changes.
Also how to do it with the mentioned Java/Python scripts, as we have it done
with our release step-by-step guide. I didn't know these scripts and nobody
told me about their existence. I was not able to find a WIKI page about it
(with my mobile phone ;-) ). I could imagine, I'm not the only one...
> Thanks in advance for clarification,
> Christian
>
> Sent from a mobile device
>
> Am 22.09.2011 10:12 schrieb "Guillaume Nodet" <gn...@gmail.com>:
>
> > Fwiw, git-svn could be handy too ... as merges are really easy with git.
> >
> > On Thu, Sep 22, 2011 at 19:02, Daniel Kulp <dk...@apache.org> wrote:
> >
> >> On Thursday, September 22, 2011 6:44:42 PM Claus Ibsen wrote:
> >> > Hi
> >> >
> >> > I gave the DoMerges tool a try and it worked fine.
> >> >
> >> > However as my svnmerge.py python script causes some UTF-8 error after
> >> > the merge is done, the DoMerges tool breaks
> >> > after one merge.
> >> >
> >> > I tried downloading the latest svnerge.py file from the official
> >> > source but it fails as well.
> >> > I guess I need to find an older svnmerge.py file that dont fail at
the
> >> end.
> >> >
> >> > If anyone got a .py file working, then feel free to attach on a mail
> >> > and send to me, or this @dev.
> >>
> >>
> >> I've attached mine. What kind of error were you getting? Does it fail
> >> outside the tool as well?
> >>
> >> What is your LANG env variable set to?
> >>
> >>
> >> Dan
> >>
> >>
> >>
> >>
> >>
> >> >
> >> > On Thu, Sep 22, 2011 at 3:34 PM, Daniel Kulp <dk...@apache.org>
wrote:
> >> > > On Thursday, September 22, 2011 7:45:28 AM Claus Ibsen wrote:
> >> > >> On Wed, Sep 21, 2011 at 4:23 PM, Daniel Kulp <dk...@apache.org>
> >> wrote:
> >> > >> > I agree that I should have given a better "hey, ton of stuff
going
> >> > >> > to
> >> > >> > happen" heads up Monday morning (or Friday).
> >> > >>
> >> > >> Thanks. We are not accustomed to see 70-100 backports on the 2.x
> >> > >> branch overnight.
> >> > >> So we were wonder what happened. If some auto tool have been
enabled
> >> > >> or
> >> > >> whatnot?
> >> > >
> >> > > I really hate to point this out as it's a bit of an embarrassment
to
> >> me,
> >> > > but since you mentioned it.......
> >> > >
> >> > > If you look in:
> >> > > http://svn.apache.org/repos/asf/cxf/trunk/bin/
> >> > >
> >> > > there is a DoMerges.java file in there that you can compile and run
> >> from
> >> > > a fixes branch checkout.. It pretty much walks you through the
> >> > > entire process of backporting fixes. It lists all the outstanding
> >> > > commits that haven't been reviewed, allows you to [M]erge commits
> >> > > individually, [B]lock commits (reviewed and shouldn't be merged
back),
> >> > > show the diffs, etc..... Glen added some good comment to the top of
> >> > > it a couple weeks ago. For the most part, it's quite easy to walk
> >> > > through a bunch of commits and merge things back with it. Takes
very
> >> > > little time. (one enhancement I plan to add is to have it print the
> >> > > URL to the viewvc for the commit and the full URL to the JIRA if
there
> >> > > is one mentioned. Little easier than the pure diffs.) In anycase,
> >> > > while not a complete "auto tool" that was used, it isn't hard to go
> >> > > through a lot of commits.
> >> > >
> >> > > Why is it embarrassing to me? Well, it's a silly little Java
program
> >> > > that is doing the job of something SHOULD have been written in
python
> >> > > or perl or even bash. I'll readily admit that. Best tool for the
> >> > > job was definitely not applied here.
> >> > >
> >> > >
> >> > > --
> >> > > Daniel Kulp
> >> > > dkulp@apache.org
> >> > > http://dankulp.com/blog
> >> > > Talend - http://www.talend.com
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org
> >> http://dankulp.com/blog
> >> Talend - http://www.talend.com
> >>
> >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Christian Müller <ch...@gmail.com>.
Now it's a bit more clearer, but not totally.
IMO, we only backported bugs and dependency changes which are bugfix
versions in the past. With Camel 2.8.2, we backported much more - mostly
all. I've expected a [DISCUSS] about this - not only a [HEADS UP]. I'm sure
Dan has good reasons for this, but it shoud be discussed first.
We backported mostly all changes (which doesn't break users existing code)
into the 2.8 branch, but only a few changes into the 2.7 branch. Why? As
Hadrian mentioned in the board report, the 2.7 branch is still in
maintenance.
When I'm back, I will add a WIKI page which describes our development
process/policy for backporting changes.
Thanks in advance for clarification,
Christian
Sent from a mobile device
Am 22.09.2011 10:12 schrieb "Guillaume Nodet" <gn...@gmail.com>:
> Fwiw, git-svn could be handy too ... as merges are really easy with git.
>
> On Thu, Sep 22, 2011 at 19:02, Daniel Kulp <dk...@apache.org> wrote:
>
>> On Thursday, September 22, 2011 6:44:42 PM Claus Ibsen wrote:
>> > Hi
>> >
>> > I gave the DoMerges tool a try and it worked fine.
>> >
>> > However as my svnmerge.py python script causes some UTF-8 error after
>> > the merge is done, the DoMerges tool breaks
>> > after one merge.
>> >
>> > I tried downloading the latest svnerge.py file from the official
>> > source but it fails as well.
>> > I guess I need to find an older svnmerge.py file that dont fail at the
>> end.
>> >
>> > If anyone got a .py file working, then feel free to attach on a mail
>> > and send to me, or this @dev.
>>
>>
>> I've attached mine. What kind of error were you getting? Does it fail
>> outside the tool as well?
>>
>> What is your LANG env variable set to?
>>
>>
>> Dan
>>
>>
>>
>>
>>
>> >
>> > On Thu, Sep 22, 2011 at 3:34 PM, Daniel Kulp <dk...@apache.org> wrote:
>> > > On Thursday, September 22, 2011 7:45:28 AM Claus Ibsen wrote:
>> > >> On Wed, Sep 21, 2011 at 4:23 PM, Daniel Kulp <dk...@apache.org>
>> wrote:
>> > >> > I agree that I should have given a better "hey, ton of stuff going
>> > >> > to
>> > >> > happen" heads up Monday morning (or Friday).
>> > >>
>> > >> Thanks. We are not accustomed to see 70-100 backports on the 2.x
>> > >> branch overnight.
>> > >> So we were wonder what happened. If some auto tool have been enabled
>> > >> or
>> > >> whatnot?
>> > >
>> > > I really hate to point this out as it's a bit of an embarrassment to
>> me,
>> > > but since you mentioned it.......
>> > >
>> > > If you look in:
>> > > http://svn.apache.org/repos/asf/cxf/trunk/bin/
>> > >
>> > > there is a DoMerges.java file in there that you can compile and run
>> from
>> > > a fixes branch checkout.. It pretty much walks you through the
>> > > entire process of backporting fixes. It lists all the outstanding
>> > > commits that haven't been reviewed, allows you to [M]erge commits
>> > > individually, [B]lock commits (reviewed and shouldn't be merged
back),
>> > > show the diffs, etc..... Glen added some good comment to the top of
>> > > it a couple weeks ago. For the most part, it's quite easy to walk
>> > > through a bunch of commits and merge things back with it. Takes very
>> > > little time. (one enhancement I plan to add is to have it print the
>> > > URL to the viewvc for the commit and the full URL to the JIRA if
there
>> > > is one mentioned. Little easier than the pure diffs.) In anycase,
>> > > while not a complete "auto tool" that was used, it isn't hard to go
>> > > through a lot of commits.
>> > >
>> > > Why is it embarrassing to me? Well, it's a silly little Java program
>> > > that is doing the job of something SHOULD have been written in python
>> > > or perl or even bash. I'll readily admit that. Best tool for the
>> > > job was definitely not applied here.
>> > >
>> > >
>> > > --
>> > > Daniel Kulp
>> > > dkulp@apache.org
>> > > http://dankulp.com/blog
>> > > Talend - http://www.talend.com
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>> Talend - http://www.talend.com
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Guillaume Nodet <gn...@gmail.com>.
Fwiw, git-svn could be handy too ... as merges are really easy with git.
On Thu, Sep 22, 2011 at 19:02, Daniel Kulp <dk...@apache.org> wrote:
> On Thursday, September 22, 2011 6:44:42 PM Claus Ibsen wrote:
> > Hi
> >
> > I gave the DoMerges tool a try and it worked fine.
> >
> > However as my svnmerge.py python script causes some UTF-8 error after
> > the merge is done, the DoMerges tool breaks
> > after one merge.
> >
> > I tried downloading the latest svnerge.py file from the official
> > source but it fails as well.
> > I guess I need to find an older svnmerge.py file that dont fail at the
> end.
> >
> > If anyone got a .py file working, then feel free to attach on a mail
> > and send to me, or this @dev.
>
>
> I've attached mine. What kind of error were you getting? Does it fail
> outside the tool as well?
>
> What is your LANG env variable set to?
>
>
> Dan
>
>
>
>
>
> >
> > On Thu, Sep 22, 2011 at 3:34 PM, Daniel Kulp <dk...@apache.org> wrote:
> > > On Thursday, September 22, 2011 7:45:28 AM Claus Ibsen wrote:
> > >> On Wed, Sep 21, 2011 at 4:23 PM, Daniel Kulp <dk...@apache.org>
> wrote:
> > >> > I agree that I should have given a better "hey, ton of stuff going
> > >> > to
> > >> > happen" heads up Monday morning (or Friday).
> > >>
> > >> Thanks. We are not accustomed to see 70-100 backports on the 2.x
> > >> branch overnight.
> > >> So we were wonder what happened. If some auto tool have been enabled
> > >> or
> > >> whatnot?
> > >
> > > I really hate to point this out as it's a bit of an embarrassment to
> me,
> > > but since you mentioned it.......
> > >
> > > If you look in:
> > > http://svn.apache.org/repos/asf/cxf/trunk/bin/
> > >
> > > there is a DoMerges.java file in there that you can compile and run
> from
> > > a fixes branch checkout.. It pretty much walks you through the
> > > entire process of backporting fixes. It lists all the outstanding
> > > commits that haven't been reviewed, allows you to [M]erge commits
> > > individually, [B]lock commits (reviewed and shouldn't be merged back),
> > > show the diffs, etc..... Glen added some good comment to the top of
> > > it a couple weeks ago. For the most part, it's quite easy to walk
> > > through a bunch of commits and merge things back with it. Takes very
> > > little time. (one enhancement I plan to add is to have it print the
> > > URL to the viewvc for the commit and the full URL to the JIRA if there
> > > is one mentioned. Little easier than the pure diffs.) In anycase,
> > > while not a complete "auto tool" that was used, it isn't hard to go
> > > through a lot of commits.
> > >
> > > Why is it embarrassing to me? Well, it's a silly little Java program
> > > that is doing the job of something SHOULD have been written in python
> > > or perl or even bash. I'll readily admit that. Best tool for the
> > > job was definitely not applied here.
> > >
> > >
> > > --
> > > Daniel Kulp
> > > dkulp@apache.org
> > > http://dankulp.com/blog
> > > Talend - http://www.talend.com
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday, September 22, 2011 6:44:42 PM Claus Ibsen wrote:
> Hi
>
> I gave the DoMerges tool a try and it worked fine.
>
> However as my svnmerge.py python script causes some UTF-8 error after
> the merge is done, the DoMerges tool breaks
> after one merge.
>
> I tried downloading the latest svnerge.py file from the official
> source but it fails as well.
> I guess I need to find an older svnmerge.py file that dont fail at the end.
>
> If anyone got a .py file working, then feel free to attach on a mail
> and send to me, or this @dev.
I've attached mine. What kind of error were you getting? Does it fail
outside the tool as well?
What is your LANG env variable set to?
Dan
>
> On Thu, Sep 22, 2011 at 3:34 PM, Daniel Kulp <dk...@apache.org> wrote:
> > On Thursday, September 22, 2011 7:45:28 AM Claus Ibsen wrote:
> >> On Wed, Sep 21, 2011 at 4:23 PM, Daniel Kulp <dk...@apache.org> wrote:
> >> > I agree that I should have given a better "hey, ton of stuff going
> >> > to
> >> > happen" heads up Monday morning (or Friday).
> >>
> >> Thanks. We are not accustomed to see 70-100 backports on the 2.x
> >> branch overnight.
> >> So we were wonder what happened. If some auto tool have been enabled
> >> or
> >> whatnot?
> >
> > I really hate to point this out as it's a bit of an embarrassment to me,
> > but since you mentioned it.......
> >
> > If you look in:
> > http://svn.apache.org/repos/asf/cxf/trunk/bin/
> >
> > there is a DoMerges.java file in there that you can compile and run from
> > a fixes branch checkout.. It pretty much walks you through the
> > entire process of backporting fixes. It lists all the outstanding
> > commits that haven't been reviewed, allows you to [M]erge commits
> > individually, [B]lock commits (reviewed and shouldn't be merged back),
> > show the diffs, etc..... Glen added some good comment to the top of
> > it a couple weeks ago. For the most part, it's quite easy to walk
> > through a bunch of commits and merge things back with it. Takes very
> > little time. (one enhancement I plan to add is to have it print the
> > URL to the viewvc for the commit and the full URL to the JIRA if there
> > is one mentioned. Little easier than the pure diffs.) In anycase,
> > while not a complete "auto tool" that was used, it isn't hard to go
> > through a lot of commits.
> >
> > Why is it embarrassing to me? Well, it's a silly little Java program
> > that is doing the job of something SHOULD have been written in python
> > or perl or even bash. I'll readily admit that. Best tool for the
> > job was definitely not applied here.
> >
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://dankulp.com/blog
> > Talend - http://www.talend.com
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I gave the DoMerges tool a try and it worked fine.
However as my svnmerge.py python script causes some UTF-8 error after
the merge is done, the DoMerges tool breaks
after one merge.
I tried downloading the latest svnerge.py file from the official
source but it fails as well.
I guess I need to find an older svnmerge.py file that dont fail at the end.
If anyone got a .py file working, then feel free to attach on a mail
and send to me, or this @dev.
On Thu, Sep 22, 2011 at 3:34 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Thursday, September 22, 2011 7:45:28 AM Claus Ibsen wrote:
>> On Wed, Sep 21, 2011 at 4:23 PM, Daniel Kulp <dk...@apache.org> wrote:
>> > I agree that I should have given a better "hey, ton of stuff going to
>> > happen" heads up Monday morning (or Friday).
>>
>> Thanks. We are not accustomed to see 70-100 backports on the 2.x
>> branch overnight.
>> So we were wonder what happened. If some auto tool have been enabled or
>> whatnot?
>
> I really hate to point this out as it's a bit of an embarrassment to me, but
> since you mentioned it.......
>
> If you look in:
> http://svn.apache.org/repos/asf/cxf/trunk/bin/
>
> there is a DoMerges.java file in there that you can compile and run from a
> fixes branch checkout.. It pretty much walks you through the entire process
> of backporting fixes. It lists all the outstanding commits that haven't been
> reviewed, allows you to [M]erge commits individually, [B]lock commits
> (reviewed and shouldn't be merged back), show the diffs, etc..... Glen added
> some good comment to the top of it a couple weeks ago. For the most part,
> it's quite easy to walk through a bunch of commits and merge things back with
> it. Takes very little time. (one enhancement I plan to add is to have it
> print the URL to the viewvc for the commit and the full URL to the JIRA if
> there is one mentioned. Little easier than the pure diffs.) In anycase,
> while not a complete "auto tool" that was used, it isn't hard to go through a
> lot of commits.
>
> Why is it embarrassing to me? Well, it's a silly little Java program that is
> doing the job of something SHOULD have been written in python or perl or even
> bash. I'll readily admit that. Best tool for the job was definitely not
> applied here.
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday, September 22, 2011 7:45:28 AM Claus Ibsen wrote:
> On Wed, Sep 21, 2011 at 4:23 PM, Daniel Kulp <dk...@apache.org> wrote:
> > I agree that I should have given a better "hey, ton of stuff going to
> > happen" heads up Monday morning (or Friday).
>
> Thanks. We are not accustomed to see 70-100 backports on the 2.x
> branch overnight.
> So we were wonder what happened. If some auto tool have been enabled or
> whatnot?
I really hate to point this out as it's a bit of an embarrassment to me, but
since you mentioned it.......
If you look in:
http://svn.apache.org/repos/asf/cxf/trunk/bin/
there is a DoMerges.java file in there that you can compile and run from a
fixes branch checkout.. It pretty much walks you through the entire process
of backporting fixes. It lists all the outstanding commits that haven't been
reviewed, allows you to [M]erge commits individually, [B]lock commits
(reviewed and shouldn't be merged back), show the diffs, etc..... Glen added
some good comment to the top of it a couple weeks ago. For the most part,
it's quite easy to walk through a bunch of commits and merge things back with
it. Takes very little time. (one enhancement I plan to add is to have it
print the URL to the viewvc for the commit and the full URL to the JIRA if
there is one mentioned. Little easier than the pure diffs.) In anycase,
while not a complete "auto tool" that was used, it isn't hard to go through a
lot of commits.
Why is it embarrassing to me? Well, it's a silly little Java program that is
doing the job of something SHOULD have been written in python or perl or even
bash. I'll readily admit that. Best tool for the job was definitely not
applied here.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Sep 22, 2011 at 4:08 AM, Christian Müller
<ch...@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<cl...@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: cibsen@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
>>>>>>> dkulp@apache.org
>>>>>>> http://dankulp.com/blog
>>>>>>> Talend - http://www.talend.com
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://dankulp.com/blog
>>> Talend - http://www.talend.com
>>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Sep 22, 2011 at 4:17 AM, Johan Edstrom <se...@gmail.com> wrote:
> I'll step in here…
>
> Much of what Dan has done is in the corporate world very very much wanted.
> Dan offered his time to keep on back porting fixing and non api breaking features.
>
Dan is not the only person doing this. We are already backporting to
the 2.8 branch. Also after the 2.8.1 release.
Well there were some API breakings in there, however on the small side
as they face internally,
but still. Some commits wasn't necessary to backport as they cases
these minor/micro API changes.
> That means we'll see (and we can debate that) "done in 2.9, available in 2.8.5)
>
> I think Dan already said he should have said more of a "hey", debating if we need this is
> going to go in the insane bin, most customers I work with complain about the lack of a
> stable train that provides fixes with no upgrades….
>
The 2.8.2 would have become more stable if there was not backported
soo many changes.
> /je
>
> On Sep 21, 2011, at 8:08 PM, Christian Müller wrote:
>
>> 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<cl...@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: cibsen@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
>>>>>>>> dkulp@apache.org
>>>>>>>> http://dankulp.com/blog
>>>>>>>> Talend - http://www.talend.com
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org
>>>> http://dankulp.com/blog
>>>> Talend - http://www.talend.com
>>>
>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Johan Edstrom <se...@gmail.com>.
I'll step in here…
Much of what Dan has done is in the corporate world very very much wanted.
Dan offered his time to keep on back porting fixing and non api breaking features.
That means we'll see (and we can debate that) "done in 2.9, available in 2.8.5)
I think Dan already said he should have said more of a "hey", debating if we need this is
going to go in the insane bin, most customers I work with complain about the lack of a
stable train that provides fixes with no upgrades….
/je
On Sep 21, 2011, at 8:08 PM, Christian Müller wrote:
> 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<cl...@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: cibsen@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
>>>>>>> dkulp@apache.org
>>>>>>> http://dankulp.com/blog
>>>>>>> Talend - http://www.talend.com
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://dankulp.com/blog
>>> Talend - http://www.talend.com
>>
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Christian Schneider <ch...@die-schneider.net>.
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<cl...@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: cibsen@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
>>>>>>> dkulp@apache.org
>>>>>>> http://dankulp.com/blog
>>>>>>> Talend - http://www.talend.com
>>> --
>>> Daniel Kulp
>>> dkulp@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
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Christian Müller <ch...@gmail.com>.
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<cl...@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: cibsen@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
>>>>>> dkulp@apache.org
>>>>>> http://dankulp.com/blog
>>>>>> Talend - http://www.talend.com
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>> Talend - http://www.talend.com
>
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Rob Davies <ra...@gmail.com>.
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<cl...@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: cibsen@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
>>>>> dkulp@apache.org
>>>>> http://dankulp.com/blog
>>>>> Talend - http://www.talend.com
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Sep 21, 2011 at 4:23 PM, Daniel Kulp <dk...@apache.org> 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).
>
Thanks. We are not accustomed to see 70-100 backports on the 2.x
branch overnight.
So we were wonder what happened. If some auto tool have been enabled or whatnot?
> 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. :-(
>
I think its better to have the person who worked on the ticket
backport the ticket.
For example as myself, Willem and some others already do. After the
changes is committed
to trunk, we take time to backport it as well.
The reason is that we know best if that ticket would be good to packport or not.
Going forward, it may be a good idea to put a note in the JIRA ticket
if the ticket is not ideal to backport.
> 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.
>
Good idea, but see above. We should do both. Have the habit of
backport the change at the same
time you commit to trunk. Then its fresh in memory and we get it done
at the best time.
Having a semi-weekly basis as well, helps make sure we catch tickets
which for some reason wasn't,
or there has come up good cause to backport some tickets etc.
>
> 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<cl...@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: cibsen@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
>> >>> dkulp@apache.org
>> >>> http://dankulp.com/blog
>> >>> Talend - http://www.talend.com
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Daniel Kulp <dk...@apache.org>.
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<cl...@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: cibsen@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
> >>> dkulp@apache.org
> >>> http://dankulp.com/blog
> >>> Talend - http://www.talend.com
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Rob Davies <ra...@gmail.com>.
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<cl...@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: cibsen@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
>>> dkulp@apache.org
>>> http://dankulp.com/blog
>>> Talend - http://www.talend.com
>>
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Hadrian Zbarcea <hz...@gmail.com>.
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<cl...@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: cibsen@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
>> dkulp@apache.org
>> http://dankulp.com/blog
>> Talend - http://www.talend.com
>
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Rob Davies <ra...@gmail.com>.
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 <cl...@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: cibsen@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
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Daniel Kulp <dk...@apache.org>.
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 <cl...@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: cibsen@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
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Claus Ibsen <cl...@gmail.com>.
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.
So the gap from 2.8.0, 2.8.1 to 2.8.2 is now very big. This is not desireable.
On Tue, Sep 20, 2011 at 8:11 AM, Claus Ibsen <cl...@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.
>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Camel 2.8.2 - Reason for the many backports?
Posted by Jon Anstey <ja...@gmail.com>.
Yeah, I don't like the idea of too many features going into the bug fix
branch... I'd say don't do it unless there is a good reason. Well, we don't
really have any rules for what goes into one of these branches so it is
probably not so clear :)
We should really keep the docs up to date though when merging
improvements/features. I'll update the docs for CAMEL-4290, CAMEL-4297,
CAMEL-4382 since I originally committed them but there still may be more
that need to be updated.
On Tue, Sep 20, 2011 at 3:41 AM, Claus Ibsen <cl...@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.
>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
--
Cheers,
Jon
---------------
FuseSource
Email: jon@fusesource.com
Web: fusesource.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen