On 1 November 2015 at 02:08, Barry Warsaw <ba...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
