On 17 January 2016 at 23:20, Oleg Broytman <[email protected]> wrote: > On Sun, Jan 17, 2016 at 08:48:42PM +0000, Brett Cannon <[email protected]> > wrote: >> 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
In theory I would also prefer sticking with the current process of merging the 3.x branches, and only cherry-picking for the 2.7 branch. Are there any more details on this decision? When making a patch for review I currently do it off the “default” branch, because then one patch will usually encompass all the changes needed (but a patch against 3.5 for instance may miss an API added in 3.6). But when actually making a commit I think it is better to commit first to 3.5 (for instance). For handling pull requests from others, I can see that having the pull request against master would be easier for the original contributor. On the other hand, if the contributor were able to pre-arrange all the merges between branches (including resolving conflicts), it might be help the person doing the final push. But maybe this is too complicated for all parties; I dunno. _______________________________________________ core-workflow mailing list [email protected] https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
