On Sun, 16 Aug 2015 00:13:10 -0700, 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?
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 _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers