[Python-Dev] [python-committers] How are we merging forward from the Bitbucket 3.5 repo?
Guido van Rossum
guido at python.org
Sun Aug 16 16:08:03 CEST 2015
I presume the issue here is that Hg is so complicated that everyone knows a
different subset of the commands and semantics.
I personally don't know what the commands for cherry-picking a revision
would be.
I also don't know exactly what happens when you merge a PR using bitbucket.
(I'm only familiar with the GitHub PR flow, and I don't like its behavior,
which seems to always create an extra merge revision for what I consider as
logically a single commit.)
BTW When I go to https://bitbucket.org/larry/cpython350 the first thing I
see (in a very big bold font) is "This is Python version 3.6.0 alpha 1".
What's going on here? It doesn't inspire confidence.
On Sun, Aug 16, 2015 at 10:13 AM, 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?
>
>
> */arry*
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
>
--
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150816/33bd6bed/attachment.html>
More information about the Python-Dev
mailing list