On Sun, 17 Jan 2016 at 16:42 Martin Panter <vadmium+py@gmail.com> wrote:
On 17 January 2016 at 23:20, Oleg Broytman <phd@phdru.name> wrote:
On Sun, Jan 17, 2016 at 08:48:42PM +0000, Brett Cannon <brett@python.org> 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...
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.