brooklyn-dev mailing list archives

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

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
https://help.github.com/articles/checking-out-pull-requests-locally

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 <alex.heneveld@cloudsoftcorp.com> 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 <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
>
>

Mime
View raw message