You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Richard Downer <ri...@apache.org> on 2014/05/22 15:22:13 UTC
Mirroring to GitHub
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
Re: Mirroring to GitHub
Posted by Richard Downer <ri...@apache.org>.
Yes. jclouds and Usergrid both do this. My message was describing the
different approaches they have taken and what we can blatantly
copy^W^W reuse effectively.
On 22 May 2014 14:31, Martin Harris <ma...@cloudsoftcorp.com> wrote:
> If we adopt the model where Apache is the source of truth, can we still
> issue PRs against github?
>
> Cheers
>
> M
>
>
> On 22 May 2014 14:22, Richard Downer <ri...@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
>>
>
>
>
> --
> Martin Harris
> Lead Software Engineer
> Cloudsoft Corporation Ltd
> www.cloudsoftcorp.com
> Mobile: +44 (0)7989 047-855
Re: Mirroring to GitHub
Posted by Martin Harris <ma...@cloudsoftcorp.com>.
If we adopt the model where Apache is the source of truth, can we still
issue PRs against github?
Cheers
M
On 22 May 2014 14:22, Richard Downer <ri...@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
>
--
Martin Harris
Lead Software Engineer
Cloudsoft Corporation Ltd
www.cloudsoftcorp.com
Mobile: +44 (0)7989 047-855
Re: Mirroring to GitHub
Posted by Chip Childers <ch...@apache.org>.
On Fri, May 30, 2014 at 03:26:07AM +0100, Alex Heneveld wrote:
>
> Chip, Richard,
>
> To date we (the committers) have verified that potential contributors have a
> signed CLA with the Brooklyn project, before accepting a PR. What are the
> requirements for accepting commits into Brooklyn as an ASF project?
Having a CLA for contributions prior to CloudSoft's donation of the
project to the ASF is awesome... that gave you the right to do the
donation (I assume, since I have not read the CLA).
That said, the older agreement has no standing for the ASF. See my
comments in reply to Richard's email about the way that we ensure that
someone wanted to donate *to Apache Brooklyn* vs something else.
>
> Presumably we need to check whether a person has a CLA on file with the ASF.
> Is there a checklist of other things?
CLA's are not strictly required, and there is a bit of a fuzzy gray area
about the size of a contribution that triggers the requirement for an
ICLA. Small patches, don't worry about it... larger patches, start
considering it.
As an aside, it seems to me that if you have people that have been
consistently contributing enough to the project that you know they have
CLA's on file with Brooklyn, but were not added as initial contributors
during the donation process, PPMC should plan on actively inviting these
folks to be committers (discussion of specific names should be done on
private@b.i.a.o).
>
> And how can we check whether someone has a CLA w ASF ?
>
> (It's just half a dozen contributors or so for the commits since the SGA so
> shouldn't be too hard to confirm these once we know the process.)
>
> --A
>
>
> On 29/05/2014 21:11, Chip Childers wrote:
> >Given David's comment and note about Brett's concerns with the usergrid
> >workflow, it would make sense to get the change over done now.
> >
> >One of the challenges that we have right now is that the SGA was sent in
> >to donate the Brooklyn code to the ASF. However, we're going to need to
> >review all of the commits that have been pulled into the booklyn GH repo
> >and then pushed into the ASF, to be sure that the person providing the
> >changes fully understood that they were effectively making a donation to
> >the ASF.
> >
> >This might not seem like a huge deal ATM, but IP provenance is critical to
> >the rationale behind the ASF IP management processes / policies.
> >
> >So... instead of pulling any more commits from GH, I think it's time to
> >switch to ASF as the canonical repo ASAP.
> >
> >Can you guys do that?
> >
> >-chip
>
Re: Mirroring to GitHub
Posted by Chip Childers <ch...@apache.org>.
On Fri, May 30, 2014 at 10:38:48AM +0100, Richard Downer wrote:
> Alex,
>
> As I understand it, all non-trivial changes require consent.
> (One-liners and whitespace changes could be exempt.) Consent can take
> two forms:
>
> 1 - patches submitted through Jira. I understand that when attaching a
> file to a ticket, a checkbox is provided for the user to consent to
> the license. (We should raise some test issues through Jira to confirm
> that this is the case, and to document it for our contributors.)
>
> 2 - an ICLA. The list of ICLAs on record is on this page:
> https://people.apache.org/committer-index.html (despite its name, this
> page is not *just* committers. At the end there is a section for
> non-committers who have ICLAs on file).
>
> I am not an Apache expert (yet) but this is my general understanding,
> corrections welcome.
>
> Richard.
It's really not about Jira or not Jira... it's about a clear intent to
donate the code to the ASF (and this is where the GH stuff becomes
problematic sometimes). This is why we generally consider "ASF owned"
assets to be critical. Jira, Reviewboard, dev@ mailing lists are all
valid places for someone to provide a patch.
>
>
> On 30 May 2014 03:26, Alex Heneveld <al...@cloudsoftcorp.com> wrote:
> >
> > Chip, Richard,
> >
> > To date we (the committers) have verified that potential contributors have a
> > signed CLA with the Brooklyn project, before accepting a PR. What are the
> > requirements for accepting commits into Brooklyn as an ASF project?
> >
> > Presumably we need to check whether a person has a CLA on file with the ASF.
> > Is there a checklist of other things?
> >
> > And how can we check whether someone has a CLA w ASF ?
> >
> > (It's just half a dozen contributors or so for the commits since the SGA so
> > shouldn't be too hard to confirm these once we know the process.)
> >
> > --A
> >
> >
> >
> > On 29/05/2014 21:11, Chip Childers wrote:
> >>
> >> Given David's comment and note about Brett's concerns with the usergrid
> >> workflow, it would make sense to get the change over done now.
> >>
> >> One of the challenges that we have right now is that the SGA was sent in
> >> to donate the Brooklyn code to the ASF. However, we're going to need to
> >> review all of the commits that have been pulled into the booklyn GH repo
> >> and then pushed into the ASF, to be sure that the person providing the
> >> changes fully understood that they were effectively making a donation to
> >> the ASF.
> >>
> >> This might not seem like a huge deal ATM, but IP provenance is critical to
> >> the rationale behind the ASF IP management processes / policies.
> >>
> >> So... instead of pulling any more commits from GH, I think it's time to
> >> switch to ASF as the canonical repo ASAP.
> >>
> >> Can you guys do that?
> >>
> >> -chip
> >
> >
Re: Mirroring to GitHub
Posted by Richard Downer <ri...@apache.org>.
Alex,
As I understand it, all non-trivial changes require consent.
(One-liners and whitespace changes could be exempt.) Consent can take
two forms:
1 - patches submitted through Jira. I understand that when attaching a
file to a ticket, a checkbox is provided for the user to consent to
the license. (We should raise some test issues through Jira to confirm
that this is the case, and to document it for our contributors.)
2 - an ICLA. The list of ICLAs on record is on this page:
https://people.apache.org/committer-index.html (despite its name, this
page is not *just* committers. At the end there is a section for
non-committers who have ICLAs on file).
I am not an Apache expert (yet) but this is my general understanding,
corrections welcome.
Richard.
On 30 May 2014 03:26, Alex Heneveld <al...@cloudsoftcorp.com> wrote:
>
> Chip, Richard,
>
> To date we (the committers) have verified that potential contributors have a
> signed CLA with the Brooklyn project, before accepting a PR. What are the
> requirements for accepting commits into Brooklyn as an ASF project?
>
> Presumably we need to check whether a person has a CLA on file with the ASF.
> Is there a checklist of other things?
>
> And how can we check whether someone has a CLA w ASF ?
>
> (It's just half a dozen contributors or so for the commits since the SGA so
> shouldn't be too hard to confirm these once we know the process.)
>
> --A
>
>
>
> On 29/05/2014 21:11, Chip Childers wrote:
>>
>> Given David's comment and note about Brett's concerns with the usergrid
>> workflow, it would make sense to get the change over done now.
>>
>> One of the challenges that we have right now is that the SGA was sent in
>> to donate the Brooklyn code to the ASF. However, we're going to need to
>> review all of the commits that have been pulled into the booklyn GH repo
>> and then pushed into the ASF, to be sure that the person providing the
>> changes fully understood that they were effectively making a donation to
>> the ASF.
>>
>> This might not seem like a huge deal ATM, but IP provenance is critical to
>> the rationale behind the ASF IP management processes / policies.
>>
>> So... instead of pulling any more commits from GH, I think it's time to
>> switch to ASF as the canonical repo ASAP.
>>
>> Can you guys do that?
>>
>> -chip
>
>
Re: Mirroring to GitHub
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
Chip, Richard,
To date we (the committers) have verified that potential contributors
have a signed CLA with the Brooklyn project, before accepting a PR.
What are the requirements for accepting commits into Brooklyn as an ASF
project?
Presumably we need to check whether a person has a CLA on file with the
ASF. Is there a checklist of other things?
And how can we check whether someone has a CLA w ASF ?
(It's just half a dozen contributors or so for the commits since the SGA
so shouldn't be too hard to confirm these once we know the process.)
--A
On 29/05/2014 21:11, Chip Childers wrote:
> Given David's comment and note about Brett's concerns with the usergrid
> workflow, it would make sense to get the change over done now.
>
> One of the challenges that we have right now is that the SGA was sent in
> to donate the Brooklyn code to the ASF. However, we're going to need to
> review all of the commits that have been pulled into the booklyn GH repo
> and then pushed into the ASF, to be sure that the person providing the
> changes fully understood that they were effectively making a donation to
> the ASF.
>
> This might not seem like a huge deal ATM, but IP provenance is critical to
> the rationale behind the ASF IP management processes / policies.
>
> So... instead of pulling any more commits from GH, I think it's time to
> switch to ASF as the canonical repo ASAP.
>
> Can you guys do that?
>
> -chip
Re: Mirroring to GitHub
Posted by Chip Childers <ch...@apache.org>.
Given David's comment and note about Brett's concerns with the usergrid
workflow, it would make sense to get the change over done now.
One of the challenges that we have right now is that the SGA was sent in
to donate the Brooklyn code to the ASF. However, we're going to need to
review all of the commits that have been pulled into the booklyn GH repo
and then pushed into the ASF, to be sure that the person providing the
changes fully understood that they were effectively making a donation to
the ASF.
This might not seem like a huge deal ATM, but IP provenance is critical to
the rationale behind the ASF IP management processes / policies.
So... instead of pulling any more commits from GH, I think it's time to
switch to ASF as the canonical repo ASAP.
Can you guys do that?
-chip
Re: Mirroring to GitHub
Posted by Aled Sage <al...@gmail.com>.
Thanks David,
Agreed - my vote is to go with the workflow David recommends.
Aled
p.s. if/when Usergrid have that discussion to persuade infrastructure,
the incubator and the board then we can join in. And if that workflow
becomes officially blessed then we look at switching to it.
On 29/05/2014 19:57, David Nalley wrote:
> 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 <al...@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 <ri...@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 <al...@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 <al...@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 <ri...@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 <da...@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
>>>>>>>>>> <ri...@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
>>>>>>>
Re: Mirroring to GitHub
Posted by David Nalley <da...@gnsa.us>.
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 <al...@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 <ri...@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 <al...@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 <al...@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 <ri...@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 <da...@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
>>>>>>>>> <ri...@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
>>>>>>
>>>>>>
>
Re: Mirroring to GitHub
Posted by Aled Sage <al...@cloudsoftcorp.com>.
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 <ri...@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 <al...@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 <al...@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 <ri...@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 <da...@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 <ri...@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
>>>>>
Re: Mirroring to GitHub
Posted by David Nalley <da...@gnsa.us>.
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 <ri...@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 <al...@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 <al...@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 <ri...@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 <da...@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 <ri...@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
>>>>
>>>>
>>
Re: Mirroring to GitHub
Posted by Richard Downer <ri...@apache.org>.
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 <al...@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 <al...@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 <ri...@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 <da...@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 <ri...@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
>>>
>>>
>
Re: Mirroring to GitHub
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
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 <al...@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 <ri...@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 <da...@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 <ri...@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
>>
Re: Mirroring to GitHub
Posted by Richard Downer <ri...@apache.org>.
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 <al...@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 <ri...@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 <da...@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 <ri...@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
>
>
Re: Mirroring to GitHub
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
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 <ri...@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 <da...@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 <ri...@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
Re: Mirroring to GitHub
Posted by David Nalley <da...@gnsa.us>.
The ASF _must_ be the repo of record for source code.
--David
On Thu, May 22, 2014 at 9:44 AM, Richard Downer <ri...@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 <da...@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 <ri...@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
Re: Mirroring to GitHub
Posted by Richard Downer <ri...@apache.org>.
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 <da...@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 <ri...@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
Re: Mirroring to GitHub
Posted by David Nalley <da...@gnsa.us>.
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 <ri...@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