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@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@python.org https://mail.python.org/mailman/listinfo/python-committers

-- --Guido van Rossum (python.org/~guido)

On 8/16/2015 3:13 AM, 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!

This does not work for bug fix that enters chain in 3.4.

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.

I though (normal) the approach was equivalent to 2 but in opposite order, and with with release manager being the only one to touch the release branch. Do what would be done in any case, regardless of release manager response: apply bug fix to 3.4 (if appropriate), merge into 3.5.1 and 3.6. Then request that it be pulled into the 3.5.0 side branch, which gets null merged when released. If request is denied, all done anyway. This is what I did for an Idle NEWS.txt change in 2.7.9. Benjamin pulled into the 2.7.9 release branch.

Can we pick one approach and stick with it? Pretty-please?

Its ultimately your choice, after reading responses.

tjr

The 3.5.0 patch flow question also brings up the question of how we are managing NEWS for 3.5.0 vs 3.5.1. We have some commits that are going in to both 3.5.0a2 and 3.5.1, and some that are only going in to 3.5.1. Currently the 3.5.1 NEWS says things are going in to 3.5.0a2, but that's obviously wrong.

Do we relabel the section in 3.5.1 NEWS as 3.5.1a1? That would leave us with the 3.5.1 NEWS never having the last alpha sections from 3.5.0, which is logical but might be confusing (or is that the way we've done it in the past?) Do we leave it to the RM to sort out each individual patch when he merges 3.5.0 into the 3.5 branch? That sounds like a lot of work, although if there are few enough patches that go into the alphas, it might not be too hard.

Either way, that final 3.5.0 merge is going to require an edit of the NEWS file.

Larry, how do you plan to handle this?

--David

PS: We'll also need an answer to this question for the proposed new NEWS workflow of putting the NEWS items in the tracker. We'll probably need to introduce x.y.z versions into the tracker.

On 08/16/2015 07:08 AM, Guido van Rossum wrote:

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.

There are a couple. The command you'd want for this use case is probably "hg transplant", because it lets you pull revisions from a different repo. Note that "transplant" is an extension; it's distributed with Mercurial but is turned off by default. (Presumably because it's an "unloved" feature, which seems to translate roughly to "deprecated and only minimally supported".)

The Mercurial team recommends "graft", and they also provide "rebase", but neither of those can pull revisions from another repo.

Since all revisions committed to 3.5.0 should be merged into 3.5.1 sooner or later, personally I don't see the *need* for cherry-picking.

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.)

Bitbucket doesn't appear to create any extraneous merge revisions. Of the two PRs I've accepted, only one created a merge, and that was sensible.

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.

It was displaying the readme from the default branch. We use the 3.5 branch.

I just went and looked, and there's a "default branch" option for the repo on Bitbucket. I changed it from "default" to "3.5" and now it displays "This is Python version 3.5.0 release candidate 1". Hopefully that inspires more confidence!

/ /arry/

On 08/16/2015 08:24 AM, R. David Murray wrote:

On Sun, 16 Aug 2015 00:13:10 -0700, Larry Hastings larry@hastings.org 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...!