[python-committers] How are we merging forward from the Bitbucket 3.5 repo?

[Terry Reedy]

On 8/16/2015 3:13 AM, Larry Hastings wrote:
>
>
> So far I've accepted two pull requests into
> bitbucket.com/larry/cpython350 in the 3.5 branch, what will become
> 3.5.0rc2.  As usual, it's the contributor's responsibility to merge
> forward; if their checkin goes in to 3.5, it's their responsibility to
> also merge it into the hg.python.org/cpython 3.5 branch (which will be
> 3.5.1) and default branch (which right now is 3.6).
>
> But... what's the plan here?  I didn't outline anything specific, I just
> assumed we'd do the normal thing, pulling from 3.5.0 into 3.5.1 and
> merging.  But of the two pull requests so far accepted, one was merged
> this way, though it cherry-picked the revision (skipping the pull
> request merge revision Bitbucket created), and one was checked in to
> 3.5.1 directly (no merging).
>
> I suppose we can do whatever we like.  But it'd be helpful if we were
> consistent.  I can suggest three approaches:
>
>  1. After your push request is merged, you cherry-pick your revision
>     from bitbucket.com/larry/cpython350 into hg.python.org/cpython and
>     merge.  After 3.5.0 final is released I do a big null merge from
>     bitbucket.com/larry/cpython350 into hg.python.org/cpython.
>  2. After your push request is merged, you manually check in a new
>     equivalent revision into hg.python.org/cpython in the 3.5 branch.
>     No merging necessary because from Mercurial's perspective it's
>     unrelated to the revision I accepted.  After 3.5.0 final is released
>     I do a big null merge from bitbucket.com/larry/cpython350 into
>     hg.python.org/cpython.
>  3. After your push request is merged, you pull from
>     bitbucket.com/larry/cpython350 into hg.python.org/cpython and merge
>     into 3.5.  In this version I don't have to do a final null merge!

This does not work for bug fix that enters chain in 3.4.

> I'd prefer 3; that's what we normally do, and that's what I was
> expecting.  So far people have done 1 and 2.

I though (normal) the approach was equivalent to 2 but in opposite 
order, and with with release manager being the only one to touch the 
release branch.  Do what would be done in any case, regardless of 
release manager response: apply bug fix to 3.4 (if appropriate), merge 
into 3.5.1 and 3.6.  Then request that it be pulled into the 3.5.0 side 
branch, which gets null merged when released.  If request is denied, all 
done anyway.  This is what I did for an Idle NEWS.txt change in 2.7.9. 
Benjamin pulled into the 2.7.9 release branch.

 > Can we pick one approach and stick with it?  Pretty-please?

Its ultimately your choice, after reading responses.

tjr