<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, 17 Jan 2016 at 15:20 Oleg Broytman <<a href="mailto:phd@phdru.name">phd@phdru.name</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<br>
On Sun, Jan 17, 2016 at 08:48:42PM +0000, Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> wrote:<br>
> Change sys._mercurial<br>
> '''''''''''''''''''''<br>
> Once Python is no longer kept in Mercurial, the ``sys._mercurial``<br>
> attribute will need to be removed. An equivalent ``sys._git``<br>
> attribute will be needed to take its place.<br>
<br>
   Shouldn't there be a sys._vcs with possible values 'subversion',<br>
'mercurial' or 'git'? Well, currently it can be only 'git', of course,<br>
but in the future it will change.<br></blockquote><div><br></div><div>This was discussed already the first time the attribute was added for Subversion and the decision that a VCS-specific attribute was preferred.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Rejected Ideas<br>
> ==============<br>
> Commit multi-release changes in bugfix branch first<br>
> ---------------------------------------------------<br>
> As the current development process has changes committed in the<br>
> oldest branch first and then merged up to the default branch, the<br>
> question came up as to whether this workflow should be perpetuated.<br>
> In the end it was decided that committing in the newest branch and<br>
> then cherrypicking changes into older branches would work best as<br>
<br>
   That's a rather strange workflow. Gitworkflows recommands against<br>
it [1], people recommends against it [2], [3].<br>
<br>
> most people will instinctively work off the newest branch and it is a<br>
> more common workflow when using Git [#git]_.<br>
<br>
   Most people commit to master because most [visible] repositories are<br>
for web sites/services/applications that don't have many branches. But<br>
for a project with a lot of release branches merge workflow is usually<br>
recommended.<br>
<br>
1. <a href="https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html" rel="noreferrer" target="_blank">https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html</a><br>
2. <a href="https://stackoverflow.com/a/1241829" rel="noreferrer" target="_blank">https://stackoverflow.com/a/1241829</a><br>
3. <a href="http://dan.bravender.net/2011/10/20/Why_cherry-picking_should_not_be_part_of_a_normal_git_workflow.html" rel="noreferrer" target="_blank">http://dan.bravender.net/2011/10/20/Why_cherry-picking_should_not_be_part_of_a_normal_git_workflow.html</a></blockquote><div><br></div><div>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.</div></div></div>