[core-workflow] Questions about the proposed workflows

[Brett Cannon]

Any news from the gitlab CEO about what they will offer and what the plan
is? I'm still aiming to get everything squared away by Dec 15 so I have 2
weeks to think things through.

On Tue, 1 Dec 2015, 17:48 Barry Warsaw <barry at python.org> wrote:

> On Dec 01, 2015, at 11:24 PM, Brett Cannon wrote:
>
> >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?
>
> I think "merge turds" and intermediate commits are kind of two separate
> things and GitLab makes some of what you want possible.
>
> If you don't want a merge commit, you'll want a fast-forward merge, which
> basically just moves the HEAD ref forward to the commit at the end of the
> source branch.  This might require a rebase if the source branch is behind
> the
> target branch.
>
> With GitLab, under a project's settings, you have an option to only accept
> fast-forward merges.  If you enable this, you get a second option to
> present a
> rebase button on accepted merge proposals.  We could enable them both, and
> this would allow (but not force) a merge proposal which applies cleanly
> (e.g. no conflicts) to be rebased and then fast-forward merged through the
> web
> into the target branch.  Thus, no merge commit.
>
> However I think removing the intermediate commits require an interactive
> rebase to squash commits on the source branch.  GitLab doesn't provide a
> through-the-web interface to interactive rebases.  You'd have to use the
> command line for this, and I often do that when I want to make local
> cleanups
> to the source branch.
>
> >The GitLab-specific question is what, if anything, is GitLab prepared to
> >offer us? Both Nick and Barry have hinted that GitLab would host us,
> listen
> >to our needs, etc., but it has always seemed to be speculation. Do we have
> >concrete information as to what GitLab is willing to do for us?
>
> I think partly it depends on what we want.  I've thought we wanted a
> dedicated
> VM, running a GitLab CE or EE instance, responding to git{,lab}.python.org
> .
> But I don't know whether we want console/sudo access, we want to run our
> own
> backups, whether that VM would be in our DC or theirs, etc.  Where does the
> dial between completely hands-off to self-hosted point?
>
> I've traded a few emails with the CEO of GitLab, who certainly seems eager
> to
> help us, but we haven't sussed out any of these details.
>
> Cheers,
> -Barry
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151211/e2142405/attachment.html>