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
