On 12 December 2015 at 10:24, Brett Cannon <br...@python.org> wrote: > On Fri, 11 Dec 2015 at 07:33 Barry Warsaw <ba...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ core-workflow mailing list core-workflow@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
