Mailing-List: contact dev-help@brooklyn.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
In-Reply-To: 
 <CABQFKi0Ai-kXQ_VxnHsppZB_6e+QNNf4jTYS_Aqf8yfywj7-kQ@mail.gmail.com>
References: 
 <CABQFKi1rBHCAEhu9RoOtevfty_ajeqF27LWUmHUz=UcCBu3Rog@mail.gmail.com>
 <CAKprHVYsSUWLCqVfmbfFr8MUT5auO41a32J3oa6Ju_7BWd9AnA@mail.gmail.com>
 <CABQFKi0Ai-kXQ_VxnHsppZB_6e+QNNf4jTYS_Aqf8yfywj7-kQ@mail.gmail.com>
From: David Nalley <david@gnsa.us>
Date: Thu, 22 May 2014 09:47:15 -0400
Message-ID: 
 <CAKprHVZFiCCEZq6Zc+cmTt8Bun2UWnY6PwyPC+XOnYzez+08wA@mail.gmail.com>
Subject: Re: Mirroring to GitHub
To: dev@brooklyn.incubator.apache.org
Content-Type: text/plain; charset=UTF-8

The ASF _must_ be the repo of record for source code.

--David

On Thu, May 22, 2014 at 9:44 AM, Richard Downer <richard@apache.org> 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 <david@gnsa.us> 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 <richard@apache.org> 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
>>> (https://github.com/apache/...) 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:
>>> https://wiki.apache.org/jclouds/How%20to%20Contribute - which is
>>> basically the familiar GitHub workflow.
>>>
>>> And then a committer merges it like this:
>>> https://wiki.apache.org/jclouds/Committers%20Guide
>>>
>>> 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: https://cwiki.apache.org/confluence/display/usergrid/Contributor+Workflow+Policy
>>>
>>> However it is slightly different in the PRs are merged on GitHub, and
>>> a cron job running on people.apache.org 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
>>> people.apache.org (like Usergrid does) - you can see the results of
>>> this at https://github.com/brooklyn/brooklyn.  (Note that the Apache
>>> git mirror is not yet the authoritative source - that hasn't yet moved
>>> from https://github.com/brooklyncentral/brooklyn - 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] https://mail-archives.apache.org/mod_mbox/jclouds-dev/201401.mbox/%3C20140131204201.27h3lqui5gk4kgss%40webmail.qrmedia.com%3E
>>> [2] https://issues.apache.org/jira/browse/USERGRID-13
>>> [3] https://help.github.com/articles/checking-out-pull-requests-locally