brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Downer <>
Subject Re: Mirroring to GitHub
Date Thu, 22 May 2014 14:10:02 GMT

In answer to your question about what the jclouds-style process would
look like, I imagine the committer would do something like this..

First-time setup

Clone the Apache git repository. Add a new remote for the GitHub
repository, and configure it as in

For each PR:

Do code reviews, PR amendments, etc. on GitHub as currently - but do
not press the "Merge" button in GitHub. Instead:

% git fetch --all    # this will cause a new remote branch to appear,
called pull/github/1234
% git checkout pull/github/1234   # optional - if you want to perform
additional checks, run tests, etc.
% git checkout master; git pull --rebase   # switch to master and get
latest from Apache repo
% git merge pull/github/1234; git push   # merge and push to Apache -
same as pushing the big green Merge button

This seems pretty concise (albeit CLI driven); I'm sure a little bit
of scripting could get this down to a one-liner if needed.

On 22 May 2014 14:58, Alex Heneveld <> wrote:
> 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.
> Best
> Alex
> 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