[Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Donald Stufft]

> On Nov 23, 2014, at 4:08 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> 
> On 11/23/2014 09:38 PM, Donald Stufft wrote:
>> 
>>> On Nov 23, 2014, at 3:03 PM, Georg Brandl <g.brandl at gmx.net> wrote:
>>> 
>>> The next point is that there is no easy way to change the target branch of
>>> a pull request (on github or bitbucket).  People will usually make patches
>>> against the master branch unless told differently explicitly, which means
>>> that the pull request will also be against the master branch.  Which means,
>>> close the PR, ask submitter to resubmit against 3.x branch, or do it
>>> yourself.
>> 
>> This in particular is not really true on Github at least. By default PRs are
>> made against whichever branch you have configured as the default branch in
>> the Github UI. This does default to master but it doesn’t have to be, for
>> instance pip has this configured for the develop branch. Although I think 
>> this specific point is moot because if things were on Git it’d probably make
>> the most sense to have the default integration branch be ``master`` just like
>> for the Hg repos they use default.
> 
> Sure, although as is the majority of commits to CPython are bugfixes, which
> normally go to 2.7, 3.4 and 3.5 (master).
> 
>> Even if someone makes a PR against the wrong branch, it “degrades” into
>> essentially the same UX as you have now, you can turn a PR into a patch by
>> adding a .patch or .diff to the end of the PR URL and then you have a patch
>> file. In additional github makes it easy to check out PRs directly with only a
>> minor bit of one time configuration in your local clone. I can checkout any PR
>> by doing ``git checkout pr/1`` (replacing 1 with whatever the number is).
>> 
>> Honestly the worst part about someone sending a PR to the wrong branch is it
>> degrades into the same terrible UX that *every* patch has to go through on
>> a hg.python.org repository right now.
> 
> I'm not saying it's worse, but most of the time it's no better for the
> committer, especially since the branches have to be juggled in most cases.

Right, well if you’re just merging one branch into another you can create a PR
from one branch to another directly in the Github Web UI, which will run tests
and then you can press the merge button on that PR too. It’s something like 3-4
clicks or so. If you want to selectively send a change from one branch to
another that will require manually making the change locally yea.

> 
> Although, when it's the same amount of work for the committer, but nicer for
> the contributor, that's a net win, I can see that.
> 
> What is absolutely essential though is a way to automatically open an issue
> on bugs.python.org for each PR, otherwise we have to look for issues in two
> different places.  (Sure, GH treats PRs like GH issues, but we wouldn't use
> the GH issue tracker.)

There’s a web hook that fires when a pull request is created, it could even be
smart enough to look for Issue numbers in the PR and commits so that it associates
it with an existing issue instead of creating a new issue.

You can see all of the events we can subscribe to here: https://developer.github.com/webhooks/#events

In a related note, while it’s not possible to *reject* a push if things don’t
match up it is entirely possible to detect it after the fact and send an email
out to folks or what have you. Similar to how tests themselves are done now.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA