On Tue, Sep 27, 2011 at 7:18 PM, Christian Müller
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
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
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 b
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 Jia
On Fri, Sep 23, 2011 at 3:09 PM, Willem Jiang 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.apa
On Sat, Sep 24, 2011 at 8:32 PM, Hadrian Zbarcea 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"
On Sat, Sep 24, 2011 at 7:34 PM, Christian Müller
wrote:
> Hello Claus!
>
> Thank you for your work updating the WIKI page. I didn't know them...
>
Yeah there is some good to know wiki pages for Camel team members here
http://camel.apache.org/developers.html
> But I have to "stress" this topic
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 d
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
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) W
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 vi
>> 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 o
On Fri, Sep 23, 2011 at 1:26 AM, Christian Müller
wrote:
> See my notes inline
>
> Christian
> Am 22.09.2011 13:43 schrieb "Christian Müller" >:
>>
>> 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. Wi
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
See my notes inline
Christian
Am 22.09.2011 13:43 schrieb "Christian Müller" :
>
> 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 [D
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
Fwiw, git-svn could be handy too ... as merges are really easy with git.
On Thu, Sep 22, 2011 at 19:02, Daniel Kulp 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 sc
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
On Thursday, September 22, 2011 7:45:28 AM Claus Ibsen wrote:
> On Wed, Sep 21, 2011 at 4:23 PM, Daniel Kulp 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
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
On Wed, Sep 21, 2011 at 4:23 PM, 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 g
On Thu, Sep 22, 2011 at 4:17 AM, Johan Edstrom 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
On Thu, Sep 22, 2011 at 4:08 AM, Christian Müller
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 o
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 hav
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
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
>> stabili
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
> stabi
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, befor
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
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
Completely agree - this is accepted practice for software.
On 21 Sep 2011, at 02:58, Christian Müller wrote:
> +1 for backporting issues which are considered as bug.
> +1 for backporting issues which updates a third party library in an bugfix
> version.
>
> All other backports shuld be discussed
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 lo
Maybe we can a JIRA filed to say if it need to be back port to other
version.
It could be easy for us to track the issue and update the doc.
It looks like Dan just work through the trunk commit log and back port
all those can back port the camel 2.8.x branch.
On Wed Sep 21 09:58:06 2011, Chr
+1 for backporting issues which are considered as bug.
+1 for backporting issues which updates a third party library in an bugfix
version.
All other backports shuld be discussed first.
My 2 cents,
Christian
Sent from a mobile device
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 g
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
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 litt
37 matches
Mail list logo
