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

[Georg Brandl]

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.

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

Georg