<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, 17 Jan 2016 at 16:42 Martin Panter <<a href="mailto:vadmium%2Bpy@gmail.com">vadmium+py@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 17 January 2016 at 23:20, Oleg Broytman <<a href="mailto:phd@phdru.name" target="_blank">phd@phdru.name</a>> wrote:<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>
>> 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><br>
<br>
In theory I would also prefer sticking with the current process of<br>
merging the 3.x branches, and only cherry-picking for the 2.7 branch.<br>
Are there any more details on this decision?<br></blockquote><div><br></div><div>Nothing beyond that was what people seemed to prefer when this was discussed back in November/December.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
When making a patch for review I currently do it off the “default”<br>
branch, because then one patch will usually encompass all the changes<br>
needed (but a patch against 3.5 for instance may miss an API added in<br>
3.6). But when actually making a commit I think it is better to commit<br>
first to 3.5 (for instance).<br>
<br>
For handling pull requests from others, I can see that having the pull<br>
request against master would be easier for the original contributor.<br>
On the other hand, if the contributor were able to pre-arrange all the<br>
merges between branches (including resolving conflicts), it might be<br>
help the person doing the final push. But maybe this is too<br>
complicated for all parties; I dunno.<br></blockquote><div><br></div><div>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. </div></div></div>