[Python-Dev] How are we merging forward from the Bitbucket 3.5 repo?
R. David Murray
rdmurray at bitdance.com
Sun Aug 16 17:24:32 CEST 2015
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
> 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.)
More information about the Python-Dev