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
