[Distutils] Please don't impose additional barriers to participation (was: build system abstraction PEP)

[Nick Coghlan]

On 1 November 2015 at 02:08, Barry Warsaw <barry at python.org> wrote:
> On Oct 29, 2015, at 10:52 PM, Marcus Smith wrote:
>
>>> If python-dev ends up adopting GitLab for the main PEPs repo, then we
>>> should be able to move the whole process there, rather than needing to
>>> maintain a separate copy.
>>>
>>will that be as open as pypa/interoperability-peps?  if it's closed off such
>>that only python devs can log PRs against PEPs once they're in the system,
>>then that's no fun.  If so, I'd still want to keep pypa/interoperability-peps
>>as the front end tool for the actual change management.
>
> The way I believe it would work via GitLab is that anybody can fork the repo,
> push branches to their fork, and file PRs against the PEPs repo.  Pushing to
> the PEPs repo would be gated via privileged members of the repo's owner,
> either via git push or button push (i.e. "hey website, I'm chillin' on the
> beach with my tablet so do the merge for me!")

Exactly. The case can be made it would be more open than GitHub, since
folks should be able to log in with any of the identity providers
GitLab supports: http://doc.gitlab.com/ce/integration/omniauth.html

One of the relevant benefits of migrating to a full repository
management server (whether that's GitHub or GitLab)  is that we'll be
able to get away from the current manual approach to managing SSH keys
in favour of people uploading their own keys after authenticating with
the main web interface.

Cheers,
Nick.

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