[core-workflow] Questions about the proposed workflows

Brett Cannon brett at python.org
Fri Dec 11 19:24:59 EST 2015


On Fri, 11 Dec 2015 at 07:33 Barry Warsaw <barry at python.org> wrote:

> On Dec 11, 2015, at 03:27 AM, Brett Cannon wrote:
>
> >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.
>
> Brett, see my question from 01-Dec -


I think you mean this:
"""
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 think we should still try to outline
> what we want before we approach GitLab with our detailed request.  I want
> to
> avoid the inevitable "What will you offer us?"  "Well, what do you want?"
> back and forth.
>

The whole point of this process of having champions is you and Nick were
supposed to figure that out and present to me the best solution. :)

If you want some input from me, then I want to know if they will give us
professional hosting and would they give us an EE license (hosted by them
or self-hosted by us).


>
> Also, as PEP 481 is still in contention as the alternative, it still
> mentions
> Phabricator which I believe is off the table, so that PEP needs an update.
>

Donald already mentioned Phabricator was yanked; I basically just consider
it "GitHub" anyway. Donald's bought a new house and just moved so I won't
hold it against him for not taking the time to rush to update the PEP when
I personally know what he is currently proposing.


>
> And afaik, none of the workflow PEPs actually describe Nick's HOCAEIT
>

The what now? I don't know that acronym and Inbox couldn't find any other
reference to it in any other email.


> suggestion for getting the best out of both GitLab and GitHub.
>
> I know you want to make a decision soon, but IMHO we need to get these
> issues
> resolved before we can move forward.
>

Yes, but we have all known Nick long enough to know that he will just keep
coming up with ideas so I can't leave it open indefinitely. :) I can push
out the discussions for longer but I'm still aiming to make my decision by
January 1.

If people want a quick summary of what's bouncing around in my brain at the
moment (which means you can't hold me to this):

   -  People are familiar with GitHub (although obviously people can learn)
   - github.com has much better performance than gitlab.com (but that might
   be moot if we get professional hosting)
   - Guido prefers GitHub (which I know Guido will say shouldn't really
   matter too much but it matters to me somewhat)
   - GitLab does offer more account login flexibility (this is weak,
   though, since practically everyone has a GitHub account already, and if we
   still accept patches via bugs.python.org then it really doesn't matter)
   - GitLab's enterprise features for fast-forward and rebasing is
   intriguing (although solving the long-lived branch problem will probably
   require some bot work which makes the built-in FF/rebase stuff a lot less
   useful on their own)
   - I'm not enthralled with the idea of trying to attempt any
   bi-directional coordination between GitHub and GitLab
   - Even uni-directional coordination seems like it might be more hassle
   than it's worth (what's the point of telling people "GitHub is totally
   fine" and then having it all mirrored to GitLab, along with all of the
   technical maintenance and complications? Just to avoid upsetting some
   people from having to use GitHub since the existence of the tooling means
   we don't have to worry about vendor lock-in?)

As you can see, pretty much everything has an exception to make this all
very murky. Pity me. :P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151212/d421d5cb/attachment.html>


More information about the core-workflow mailing list