[core-workflow] Questions about the proposed workflows

[Brett Cannon]

Berker also said a bot could do the ff workflow which could also handle the
NEWS problem as well as long term branches. Assuming that's true and we
choose to solve those problems that way then it will be true on either
platform.

On Sun, 13 Dec 2015, 05:39 Donald Stufft <donald at stufft.io> wrote:

>
> > On Dec 13, 2015, at 7:55 AM, Christian Heimes <christian at python.org>
> wrote:
> >
> > On 2015-12-02 00:32, Donald Stufft wrote:
> >>
> >>> On Dec 1, 2015, at 6:24 PM, Brett Cannon <brett at python.org> wrote:
> >>>
> >>> It's Dec 1, which means it's time for any questions people have about
> the proposed workflows so we can get answers by Dec 15.
> >>>
> >>> I have one question that applies to both proposals and one specific to
> GitLab. The general one is whether both Guido and me can both be happy. :)
> Guido doesn't want intermediate commits nor what he calls "merge turds" to
> show up in the history. I want to be able to do merges from the browser. Do
> either GitHub or GitLab provide a way through the web UI to give Guido what
> he wants, or will it always require having a checkout and SSH keys set up
> in order to do a PR merge? If only Guido can be made happy then that means
> either proposal becomes an easy way for people to get code hosting for
> their forks and a review tool but not a PR management platform since merges
> would occur outside the website and merges would simply be a `git push`
> which is basically what we do now to do the final merge for a patch.
> >>
> >> As far as I am aware, when you merge with the browser in GitHub it
> essentially does ``git merge —no-ff`` which means there will *always* be a
> merge commit. There’s no support for a rebase workflow (where you rebase
> the branch ontop of master) or for squash merges or for FF merges.
> >
> > 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.
> >
> > Christian
>
> I actually prefer non-ff merges, but that’s something that’s going to be
> very opinion driven (to ff or not to ff). Obviously going with GitHub is
> (at least currently) choosing to go with non-ff most of the time.
>
> -----------------
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
> DCFA
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151213/3d3c9878/attachment.html>