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 Fri, 23 May 2014 09:00:08 GMT
Alex,

I think I have to disagree with you - the convenience of a GUI button
versus command line is one reason, but not IMHO a compelling one.

On the other hand, a plain warning from a mentor to *not* do that is compelling!

If there's doubt over the Usergrid model, then my preference is the
jclouds model, which they have been successfully using for the last
year. Casual contributors will see no difference at all over a
pure-GitHub process, with IMO only a small additional burden on the
committers.


Richard.

On 22 May 2014 16:33, Alex Heneveld <alex.heneveld@cloudsoftcorp.com> wrote:
>
> Richard-
>
> Well... this seems a pretty compelling reason to go with the "merge on
> github, mirror to ASF" model, with ASF being the repo of record.
>
>
>> 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.
>>
>
> Best
> Alex
>
>
>
>
> On 22/05/2014 08:10, Richard Downer wrote:
>>
>> 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