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

[Brett Cannon]

On Sun, 17 Jan 2016 at 15:20 Oleg Broytman <phd at phdru.name> wrote:

> Hi!
>
> On Sun, Jan 17, 2016 at 08:48:42PM +0000, Brett Cannon <brett at python.org>
> wrote:
> > Change sys._mercurial
> > '''''''''''''''''''''
> > Once Python is no longer kept in Mercurial, the ``sys._mercurial``
> > attribute will need to be removed. An equivalent ``sys._git``
> > attribute will be needed to take its place.
>
>    Shouldn't there be a sys._vcs with possible values 'subversion',
> 'mercurial' or 'git'? Well, currently it can be only 'git', of course,
> but in the future it will change.
>

This was discussed already the first time the attribute was added for
Subversion and the decision that a VCS-specific attribute was preferred.


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


I'm personally not going to argue about this and change the current
proposal right now, but if people want to start a new thread to discuss
whether merging up or cherry-picking down is the better workflow they can
and if consensus can be reached I will change the PEP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160118/e1013ea0/attachment.html>