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

[Oleg Broytman]

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.

> 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

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.