brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: Mirroring to GitHub
Date Sat, 24 May 2014 17:36:55 GMT
Hi folks:
So after stepping back for a moment, I asked this question to some
other folks; and the consensus was that it was a very gray area. They
suggested that I ask on the board list. I have just done that. So,
provided we aren't in a huge rush, lets wait a few days and see what
comes out of that discussion. Perhaps we'll end up with more clarity
and be able to make a more informed decision.

--David

On Fri, May 23, 2014 at 5:00 AM, Richard Downer <richard@apache.org> wrote:
> 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