On Sun, 17 Jan 2016 at 16:42 Martin Panter <[email protected]> wrote:
> 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? > Nothing beyond that was what people seemed to prefer when this was discussed back in November/December. > > 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. > 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.
_______________________________________________ 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
