brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <>
Subject Re: Mirroring to GitHub
Date Thu, 22 May 2014 13:58:21 GMT

I met several of the folks from Usergrid yesterday at Gluecon who said 
how nice it was to be able to merge directly on the project Github 
(projectX/projectX) with the ASF internal git mirroring that and the 
Apache github account (apache/projectX) mirroring that.

The ASF internal repo can still be the repo of record (which I agree it 
has to be).

The difference is the process of merging to that repo -- in the Usergrid 
model it is driven by a merge click at github, whereas in jclouds merges 
are done through a separate Apache process.  I'm not sure what that 
latter process looks like (Richard? David?) but I do like the idea of 
managing merges directly on Github, where PR's come in and we're all 
used to it.  IOW the usergrid model.

Some other comments they made, which apply in both cases, is that we'll 
have to monitor/prevent PR's against the Apache github 
(apache/projectX), and that releases have to be done against the 
internal ASF git.


On 22/05/2014 07:47, David Nalley wrote:
> The ASF _must_ be the repo of record for source code.
> --David
> On Thu, May 22, 2014 at 9:44 AM, Richard Downer <> wrote:
>> That helps narrow it down :-)
>> What aspect particularly do you think is short lived? The idea of
>> GitHub being the primary and Apache git effectively being a mirror?
>> Cheers
>> Richard.
>> On 22 May 2014 14:41, David Nalley <> wrote:
>>> You should not copy Usergrid. My suspicion is that model is short lived.
>>> --David
>>> On Thu, May 22, 2014 at 9:22 AM, Richard Downer <> wrote:
>>>> 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
>>>> ourselves.
>>>> 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
>>>> contributor:
>>>> 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
>>>> up-to-date.)
>>>> 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?
>>>> [1]
>>>> [2]
>>>> [3]

View raw message