The ASF _must_ be the repo of record for source code. --David
On Thu, May 22, 2014 at 9:44 AM, Richard Downer <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
