On Sun, 17 Jan 2016 at 15:20 Oleg Broytman <p...@phdru.name> wrote: > Hi! > > On Sun, Jan 17, 2016 at 08:48:42PM +0000, Brett Cannon <br...@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.
_______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
