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 <la...@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-committ...@python.org > https://mail.python.org/mailman/listinfo/python-committers > > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
