On 9 December 2015 at 01:41, Barry Warsaw <ba...@python.org> wrote: > As far as processing pull requests or merge requests, I don't think it much > matters. Someone could submit a pull request on github and it can be easily > (though, not automatically) merged into a gitlab origin repo. What we can't > do (I think) is let Alice commit and push to github while Bob commits and > pushes to gitlab. Now we've got DAGs that probably needs manual > reconciliation. I think we could handle that with protected branches so > *only* mirroring will be allowed in the unofficial direction.
The github2gitlab project I linked automatically converts GitHub PRs to GitLab MRs, so if we have GitLab as the master, then people would still be able to submit PRs on GitHub, core developers just couldn't accept them there (acceptance would need to happen in GitLab). The two simplest approaches being considered are "all GitHub" and "all GitLab". Any hybrid approach would necessarily be more complex, but may be worth it if it lets us gain the pros of both GitHub and GitLab, while also mitigating their cons. For the "one-off patch" case, I think we want to support at least the following: * upload a patch to bugs.python.org (as today) * submit a PR on GitHub (since that's what many intro workshops teach people) If GitLab is in the mix, then we'd have to ask whether or not we also wanted to support "submit an MR on GitLab". The reason that question matters, is that there are two main approaches to combining the two solutions: * GitHub-as-origin with read-only GitLab mirror * GitLab-as-origin with GitHub mirror (and mirrored PRs) GitHub-as-origin triggers the main con of that approach: every contributor (including core developers) needs a GitHub account if they want to benefit from the streamlined workflow. With that approach, I'm not sure we'd gain enough over the "GitHub only" approach for it to be worth the additional hassle. GitLab-as-origin, however, at least mitigates the main con of the GitLab approach, by still enabling casual contributions (e.g. to fix typos) from folks with GitHub accounts that don't want to learn a new workflow. Actually setting that up would require two additions: 1. A git hook installed on the GitLab server to push commits to the main branches back to GitHub 2. A script akin to the PR->MR component of github2gitlab to create and update MRs based on GitHub PRs 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
