Am 04.02.2011 10:54, schrieb Nick Coghlan: > On Fri, Feb 4, 2011 at 1:17 PM, Jesus Cea <j...@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 _______________________________________________ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
