Re: [python-committers] [Python-Dev] How are we merging forward from the Bitbucket 3.5 repo?
On Sun, 16 Aug 2015 00:13:10 -0700, Larry Hastings 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
Re: [python-committers] [Python-Dev] How are we merging forward from the Bitbucket 3.5 repo?
On Sun, 16 Aug 2015 11:24:32 -0400, "R. David Murray" wrote: > On Sun, 16 Aug 2015 00:13:10 -0700, Larry Hastings wrote: > > 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. Thinking about this some more I realize why I was confused. My patch/pull request was something that got committed to 3.4. In that case, to follow your 3 I'd have to leave 3.4 open until you merged the pull request, and that goes against our normal workflow. Maybe my patch will be the only exception... --David ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] How are we merging forward from the Bitbucket 3.5 repo?
On 08/16/2015 08:24 AM, R. David Murray wrote: On Sun, 16 Aug 2015 00:13:10 -0700, Larry Hastings wrote: Can we pick one approach and stick with it? Pretty-please? Pick one Larry, you are the RM :) Okay. Unsurprisingly, I pick what I called option 3 before. It's basically what we do now when checking in work to earlier-version-branches, with the added complexity of the Bitbucket repo. I just tried it and it seems fine. 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? Also, on 08/17/2015 08:03 AM, Barry Warsaw wrote: I agree with the "You're the RM, pick one" sentiment, but just want to add a plea for *documenting* whatever you choose, preferably under a big red blinky banner in the devguide. ;) I can be a good monkey and follow directions, but I just don't want to have to dig through long threads on semi-public mailing lists to figure out which buttons to push. I'll post a message describing the workflow to these two newsgroups (hopefully by today) and update the devguide (hopefully by tomorrow). There's no rush as I haven't accepted any pull requests recently, though I have a couple I should attend to. (For those waiting on a reply on pull requests, sit tight, I want to get these workflow docs done first, that way you'll know what to do if/when your pull request is accepted.) Thanks, everybody, //arry// /p.s. In case you're wondering, this RC period is way, way less stress than 3.4 was. Part of that is the workflow change, and part of it is that there just isn't that much people are trying to get in this time. In 3.4 I think I had 70 merge requests just from Victor for asyncio...! ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
