[core-workflow] Questions about the proposed workflows

[Nick Coghlan]

On 12 December 2015 at 10:24, Brett Cannon <brett at python.org> wrote:
> On Fri, 11 Dec 2015 at 07:33 Barry Warsaw <barry at python.org> wrote:
>> 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. :)

Hey, I resemble that remark! :)

The HOCAEIT comment from Barry was a reference to "Have Our Cake, And
Eat It Too", but I don't agree we need to write that up before you
make a decision - that was mostly me thinking out loud about possible
alternatives, rather than an offer to do the work to set it up.
However, the emails about it may be a useful reference if Barry wanted
to discuss it directly with GitLab (since they're clearly already
moving in that direction given the Repository Mirroring additions in
GitLab EE 8.2).

> 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?)

An analogy I've been pondering to help explain the
inclusiveness/exclusiveness aspects of decisions to use proprietary
services as part of an open source project's infrastructure is to
compare it to vegetarianism & veganism: when "Sign up to this
proprietary service" is a precondition for participation, there are
going to be folks who opt out, just as there will be folks who opt out
of community events that don't offer vegetarian or vegan meal options.
>From a practical community management perspective, the relevant part
of the analogy in relation to development tools is that when choosing
a fixed menu for a community event you either:

a. offer the vegetarian/vegan option as the only option, and aim to
make sure that even the non-vegetarians enjoy it; or
b. offer a non-vegetarian option by default, but aim to make sure the
vegetarian/vegan option is still a decent one

Switching from the analogy back to the question at hand, unless you're
actually the Free Software Foundation, being inclusive of free
software and privacy advocates when choosing workflow tools doesn't
mean adopting a categorical ban on the use of proprietary software
services, but it does mean considering what the impact will be on the
folks that choose to opt out of the proprietary dependency, and
ensuring that that alternative workflow is still a reasonable one.

In the case of a GitHub-only CPython core workflow, nothing would
change for strict free software advocates that aren't core developers:
the process will be to upload patches to Roundup as they do today.
>From there, we'll either continue reviewing them in Rietveld, or else
change those scripts to submit a PR on GitHub instead.

However, folks that are both current core developers *and* strict free
software/privacy advocates would effectively have their commit
privileges revoked if they didn't sign up for a GitHub account, as you
need one in order to upload your SSH keys. Since the goal of the
workflow changes is to make more effective use of limited core
developer time, reducing the size of that pool as a side effect really
wouldn't be a good outcome. As such, it might be worth your while to
try to quantify that more precisely by asking current core developers
their views on getting a GitHub account:

a. I already have one (happily)
b. I already have one (begrudgingly)
c. I'd happily get one
d. I'd begrudgingly get one
e. I wouldn't get one

And make it clear that failing to fill in the survey will be
interpreted as "not e".

The folks that would potentially benefit from a GitLab instance being
part of the setup are then those that fall into categories "b", "d",
and "e", and you could ask a follow-up question regarding alternatives
which they considered a preferable solution to signing up for a GitHub
account:

a. GitLab EE instance hosted and managed by GitLab, Inc
b. GitLab EE instance hosted by the PSF, and managed by GitLab, Inc
c. GitLab EE instance hosted and managed by the PSF
d. GitLab CE instance hosted and managed by the PSF

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia