[core-workflow] Questions about the proposed workflows

[Barry Warsaw]

On Dec 14, 2015, at 09:16 PM, Nick Coghlan wrote:

>GitLab actually have a useful page discussing some of the trade-offs of
>different git workflows: http://doc.gitlab.com/ee/workflow/gitlab_flow.html

Yep, this is a good page for the start of a discussion we're going to need to
have.  IMO, it doesn't focus enough on projects like Python where we don't
deploy anything but instead release regular products like tarballs.

Picking a code hosting strategy will be the "easy" part of Brett's work <wink>.
Trying to figure out the best workflow for git-based CPython development will
be the "fun" part, and the current Mercurial flow is probably not the best
approach if and when git is adopted.

>One of the points they make regarding "no commits to master, only
>merges" is that it means that regardless of whether you're working on
>a simple change that can be handled on a single commit, or a
>multi-commit feature branch, there will always be a single merge
>commit at the end, and that's what you revert if you decide to back
>out the change - you never need to ask the question "Are there
>multiple commits I need to revert in order to back that change out?".

Right, that's definitely an advantage of no-ff merge commits.  It's less of a
concern when you have to branch locally to clean up contributions because at
the end of that process, you can rebase and squash on master, and then you've
only got one commit to ff.  This rebase is safe because it's never pushed.
E.g.

Alice submits a merge request that fixes bug #3.  She doesn't include a NEWS
item, and her branch has some minor style issues that need cleaning up, but
it's generally pretty good.  Rather than nitpick Alice's contribution, Bob
fetches Alice's branch, does a few more commits locally to clean things up,
and then rebases his local copy of Alice's branch onto master, squashing
commits.  Everything looks good to Bob so he ff-merges his local branch onto
master, and pushes master.  In this case, linear ff-merges are cleaner and
just as easy to revert as a merge-commit.  It also makes it easy to cherry
pick this change into stable release branches.

In fact, we may find that bug fixes typically work this way anyway because if
they need to be backported, it can be easier to work out all the cherry picks
and do local testing on all the stable branches, then only push master and the
stable branches once everything's sorted out.  CI and the buildbots would then
run on the results and ensure everything still works.

For this reason, I'm a fan of a master-first development for bug fixes, with
cherry picking to backport fixes to stable branches as appropriate.  I'm love
to hear about alternatives, but after a lot of experimentation, this seems to
be an approach that usually works smoothly and is the easiest to understand
what happened after the fact, but it's different than our current Mercurial
workflow.

Feature branches will work differently because they won't be backported.  In
those cases, an auto-merge with or without merge commits via the web ui
could be a cleaner workflow.

>If we were to adopt the "commit to master and backport" model for maintenance
>branches, then filtering out merge commits to master should also eliminate
>most of the clutter from "git log", while still presenting the meaningful
>changes to each branch.

There's probably no easy way to eliminate manual, local work on the part of
the final committer for backporting changes from master into stable branches,
but with a careful strategy, it's not that hard either.  Sometimes there's no
way around merge conflicts though.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151214/63aac1d5/attachment.sig>