Martin v. Löwis schrieb:
>> A large merge queue would accumulate making hard for someone to pick
>> out the bugfixes. Of course, people could just merge fixes right after
>> they apply it to the trunk, though.
>
> I think they should. To my knowledge, nobody goes through the changelog
> anymore tr
> A large merge queue would accumulate making hard for someone to pick
> out the bugfixes. Of course, people could just merge fixes right after
> they apply it to the trunk, though.
I think they should. To my knowledge, nobody goes through the changelog
anymore trying to find out what needs backpo
On Thu, Oct 2, 2008 at 3:18 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>>> 2. Do bugfixes in trunk, and merge them to maint via svnmerge.
>>>Arguments as for 1, but reversed: many blocks, but less problems with 3k.
>
> I'm not so sure that we need to block all the changes that we don't
>
>> 2. Do bugfixes in trunk, and merge them to maint via svnmerge.
>>Arguments as for 1, but reversed: many blocks, but less problems with 3k.
I'm not so sure that we need to block all the changes that we don't
want, though: it would be sufficient to just not merge them, right?
(of course, som
Just now, Christian decided for option 2...
Georg
> This is another thing that needs to be discussed: how to handle backports
> between 2.6 and 2.7. Up to now, we backported changes from trunk to maint
> manually, but after the experience we've had with svnmerge, I see several
> possibilities:
>
