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

[Brett Cannon]

On Sun, 17 Jan 2016 at 16:42 Martin Panter <vadmium+py at gmail.com> wrote:

> 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?
>

Nothing beyond that was what people seemed to prefer when this was
discussed back in November/December.


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

As I said to Ezio, if people want to start a new thread to discuss this can
come back to me with a different recommendation then that's fine by me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160118/739d1b17/attachment-0001.html>