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 Thu, 29 May 2014 18:57:17 GMT
Hi Aled:

Brett Porter, the Chairman of the Board of Directors at the ASF
replied to my query on the board list. That list isn't public, so I'll
just quote a couple of sentences with his permission:

In short the message was: "we have an established and acceptable
workflow that they should use, which gives them the GitHub benefits
they want without any disagreement."

and

"If they want to push further for it, I believe the burden is on them
to come up with a process that satisfies infrastructure, the
incubator, and ultimately the board that they are properly managing
the project community and IP."

So in short - I think you are best sticking with ASF git as the
canonical repo. Use the github integration features. If you want to do
something else you have a bit of a burden to satisfy several different
groups within the Foundation, and I'd suggest that it's a distraction
during incubation.

--David



On Wed, May 28, 2014 at 11:11 AM, Aled Sage <aled.sage@cloudsoftcorp.com> wrote:
> Hi David,
>
> Are there any conclusions on the apache pull request models, discussed on
> the board list?
>
> Obviously I'm fine with us following the model used by jclouds if that is
> the conclusion for best practice.
>
> However, I will greatly miss a couple of things:
>
>  * The big easy "merge" button is a pleasure to use; compared to the
>    CLI it reduces the risk of typos for the wrong branch name etc
>  * I can review + merge code with poor internet access
>    e.g. on a train where there's little chance of me pulling down the
>    branch locally and/or pushing it to a remote server, I can currently
>    click the merge button on the github web-page.
>
> Aled
>
>
>
> On 24/05/2014 18:36, David Nalley wrote:
>>
>> 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