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

[R. David Murray]

On Sun, 16 Aug 2015 00:13:10 -0700, Larry Hastings <larry at hastings.org> 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!
> 
> 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.
> 
> Can we pick one approach and stick with it?  Pretty-please?

Pick one Larry, you are the RM :)

The reason you got different things was that how to do this was
under-specified.  Which of course we didn't realize, this being a new
procedure and all.

That said, I'm still not sure how (3) works.  Can you give us a step by
step like you did for creating the pull request?  Including how it
relates to the workflow for the other branches?  (What I did was just do
the thing I normally do, and then follow your instructions for creating
a pull request using the same patch I had previously committed to 3.4.)

--David