[core-workflow] Questions about the proposed workflows

[Guido van Rossum]

That's all fine (and I still prefer GitHub), but in the mypy I recently saw
a log like this:
```
*   7c9b2a6 Merge branch 'xxx-xxx'
|\
| * c833d7e Tweak test case
| * e52f2ff Fix crash
| * ccca8c1 Add tests for #1234
| * e870d0c Fix #1234
|/
*
```
This is clearly just some local development commits -- the entire thing
should have been a single commit labeled 'Fix #1234' (and perhaps a better
description of how or what). I guess we could request contributors to
squash the commits in the PR. But that's definitely adding extra work for
most contributors (and may add a day to the commit cycle if they've already
gone to bed or off to work or play). I can do all this manually on the
command line, but the convenience of the Merge button is pretty high...

TBH the argument from being able to roll back things doesn't feel very
strong at Dropbox. We use a merge process where developers' commits are
always squashed into a single commit in master once code review is finished
(we have command-line tools for this based on Phabricator's Arcanist). And
of course we also have to roll back stuff. But I've never heard of a
problem where we had to roll back multiple commits to get back into a
reasonable state.

Of course there are long-running projects that are committed to master in
many smaller pieces. But we take care that ever partial commit is tested
properly and we have a dynamic database of feature flags that we can use to
turn features on or off per user or group of users so we can alpha-test
committed code with select groups of users (usually Dropbox employees are
the first guinea pigs :-). Rolling back multiple commits feels like it
would be precarious -- most likely there would be merge conflicts with
other code that came in between (a lot of people typically work on the same
modules and packages).

Python development feels different -- fewer committers, fewer commits. I'm
willing to live with history like I quoted above just to have the
convenience of using the GitHub PR process, which many potential
contributors have already experienced.

On Mon, Dec 14, 2015 at 3:16 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 13 December 2015 at 22:55, Christian Heimes <christian at python.org>
> wrote:
> > Merge commits are the single most idiotic feature in GitHub because
> > GitHub enforces non fast-forward merges. Merge commits bloat and clutter
> > the revision history with useless junk, e.g.
> > http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html . We either
> > have to live with the fact that CPython's revision history is going to
> > contain lots of superfluous checkins or we cannot use the green merge
> > button at all. By the way it is not possible to disable or hide the
> > merge button. This means that we have to teach all committers to resist
> > the temptation and do a manual merge.
> >
> > GitHub claims that non-ff merges are superior because they add context
> > information to merges. The same can be accomplished with mandatory links
> > to tickets and Reviewed-by, Tested-by and Signed-off-by lines.
> >
> > I'm -1 on GitHub as long as GitHub doesn't support fast-forward merges.
>
> 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
>
> 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?".
>
> Given GitHub (and GitLab's) origins in the continuous
> integration/continuous deployment world of network service
> development, it's easy to see how that's an attractive feature: when
> committing to master triggers an automated deployment, you want the
> rollback code to be able to automatically step back to the right place
> if the initial deployments in a phased rollout indicate a bad update.
>
> That's potentially useful to us as well, since we'll likely keep
> cross-platform testing on the BuildBot fleet as a post-commit
> activity, and use something easier to scale (like Travis CI) for
> pre-commit testing.
>
> 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.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151214/ceb927c3/attachment.html>