[core-workflow] Questions about the proposed workflows

[Nick Coghlan]

On 9 December 2015 at 01:41, Barry Warsaw <barry at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia