brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Downer <>
Subject Mirroring to GitHub
Date Thu, 22 May 2014 13:22:13 GMT
Morning all,

I've been looking at how we can use Apache's git repository and still
be able to use GitHub for it's easy-to-use fork-and-pull-request style
for accepting patches from contributors. We (the people on the IPMC)
have been users and contributors of jclouds for several years, and
have watched jclouds as it went from GitHub into Apache whilst
retaining its use of GitHub, and decided this is the model to follow.
The Usergrid project is also working on doing something similar.

Infra offer a system to mirror Apache git repositories into GitHub,
and extensively integrate with Apache's mailing lists and Jira. On the
face of it this would seem perfect, but this is only available for
GitHub repos inside the "Apache" organisation
( If we want to use our own organisation
(as jclouds and Usergrid do) then we have to do more of the work

jclouds process for contributors looks like this: - which is
basically the familiar GitHub workflow.

And then a committer merges it like this:

Then, behind the scenes, a Jenkins job (not sure where) mirrors the
Apache git repo to the GitHub repo[1]

Usergrid is substantially the same from the POV of a casual

However it is slightly different in the PRs are merged on GitHub, and
a cron job running on mirrors GitHub repo to the
Apache git repo[2] (the opposite way to jclouds)

So what to do? I've prototyped a scheme where the Apache git repo is
replicated to GitHub (like jclouds does) using a cron job on (like Usergrid does) - you can see the results of
this at  (Note that the Apache
git mirror is not yet the authoritative source - that hasn't yet moved
from - so it's not quite

Under this model, the Apache git repo is the source of truth, and all
commits must be made here. Like the jclouds process, a committer must
pull the PR source into his own repository, and then push it to the
Apache git repository (fortunately a bit of Git trickery[3] can make
this painless). The cron job will then update the GitHub repo - so the
GH repo is a read-only mirror of Apache.

I like this option because it reinforces the Apache git repo as the
source of truth - however it does mean that the big green "Merge"
button in GitHub cannot be used, nor any other method of changing the
code on GitHub (as it would simply be overwritten when the 'mirror'
cron job runs next).

So - what does everyone think?


View raw message