[core-workflow] Questions about the proposed workflows

Barry Warsaw barry at python.org
Tue Dec 8 10:41:57 EST 2015


On Dec 08, 2015, at 12:46 PM, Nick Coghlan wrote:

>Something I've been pondering recently is whether we might be able to
>"have our cake and eat it too", by setting up the workflow to use
>GitHub to facilitate easy contributions by folks with a GitHub account
>(and allowing folks that don't want a GitHub account to continue
>uploading patches to the tracker), while using GitLab to continue to
>host the master repository used to make releases on a *.python.org
>subdomain.
>
>The main prompt for that thought is the fact that, with the 8.2
>release, GitLab introduced repository mirroring as a first class
>feature in the Enterprise Edition:
>https://about.gitlab.com/2015/11/22/gitlab-8-2-released/
>
>With that setup, development work would happen on GitHub and Roundup,
>while release management work would mostly happen on GitLab,
>docs.python.org and www.python.org.
>
>The question for GitLab then would be whether or not bidirectional
>syncing of pull requests/merge requests between GitHub & GitLab is on
>their radar as a possible future feature (one-way syncing is already
>possible, through projects like
>https://pypi.python.org/pypi/github2gitlab )

I don't know the answer to the latter, but I do think the repository mirroring
feature could help us here.  If we do this though, why wouldn't we also accept
merge requests on the gitlab instance?

I guess the problem is that if only gitlab can mirror, then commits to the
gitlab repo have to be manually pushed to github.  Maybe a webhook can
automate that for us.  The trick will be ensuring that we don't get into a
situation where there are conflicts when mirroring.  That can happen if
changes are merged to both the github and gitlab repos.  So I think one of
them has to the be the canonical origin and the other a mirror.

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.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151208/379ca9ea/attachment.sig>


More information about the core-workflow mailing list