[core-workflow] PEP 512: migrating hg.python.org to GitHub

[Martin Panter]

On 17 January 2016 at 23:20, Oleg Broytman <phd at phdru.name> wrote:
> On Sun, Jan 17, 2016 at 08:48:42PM +0000, Brett Cannon <brett at python.org> wrote:
>> Rejected Ideas
>> ==============
>> Commit multi-release changes in bugfix branch first
>> ---------------------------------------------------
>> As the current development process has changes committed in the
>> oldest branch first and then merged up to the default branch, the
>> question came up as to whether this workflow should be perpetuated.
>> In the end it was decided that committing in the newest branch and
>> then cherrypicking changes into older branches would work best as
>
>    That's a rather strange workflow. Gitworkflows recommands against
> it [1], people recommends against it [2], [3].
>
>> most people will instinctively work off the newest branch and it is a
>> more common workflow when using Git [#git]_.
>
>    Most people commit to master because most [visible] repositories are
> for web sites/services/applications that don't have many branches. But
> for a project with a lot of release branches merge workflow is usually
> recommended.
>
> 1. https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
> 2. https://stackoverflow.com/a/1241829
> 3. http://dan.bravender.net/2011/10/20/Why_cherry-picking_should_not_be_part_of_a_normal_git_workflow.html

In theory I would also prefer sticking with the current process of
merging the 3.x branches, and only cherry-picking for the 2.7 branch.
Are there any more details on this decision?

When making a patch for review I currently do it off the “default”
branch, because then one patch will usually encompass all the changes
needed (but a patch against 3.5 for instance may miss an API added in
3.6). But when actually making a commit I think it is better to commit
first to 3.5 (for instance).

For handling pull requests from others, I can see that having the pull
request against master would be easier for the original contributor.
On the other hand, if the contributor were able to pre-arrange all the
merges between branches (including resolving conflicts), it might be
help the person doing the final push. But maybe this is too
complicated for all parties; I dunno.