[python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

["Martin v. Löwis"]

Am 04.02.2011 10:54, schrieb Nick Coghlan:
> On Fri, Feb 4, 2011 at 1:17 PM, Jesus Cea <jcea at jcea.es> wrote:
>> "Up-porting" CAN'T be forgotten because it is done "automagically" vía
>> mercurial merges. That is the point...
> 
> So developer A checks in a fix on 2.7, then gets sidetracked before
> forward porting it.
> 
> When does it make it to 3.2 or the main development branch?
> 
> Does everyone doing a forward merge from the maintenance branches run
> the risk of being landed with the task of doing a bulk merge of any
> forgotten forward ports before they can forward port the fix they're
> actually trying to implement?

You picked the wrong example, but: yes.

Your example is wrong, because porting between 2.7 and 3.2 won't be
using any Mercurial support, and will rely on cherry-picking.

It's really the 3.2->trunk merging (and possibly 3.1->3.2->trunk
merging) that uses the Mercurial merge tracking.

If somebody commits to 3.1, and forgets to forward-merge,
the next time somebody commits to 3.1 and then wants to merge
will have to merge both changes. In the 3.2->trunk case, this
should be easy, since merges happen often, so there won't be
much pending changes (and the original committer will still
remember, and might be responsive to do the merge himself).
In the 3.1->3.2 case, if merging is forgotten, it may take
a while until somebody notices, in which case 3.2 will have
evolved, so merging becomes more difficult.

I guess it would be possible to send a daily report on pending
merges (no report if no pending merges), either to python-dev
or to the original committer (it might be also possible to determine
the original pusher, and send mail to him instead).

Regards,
Martin