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 <[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 > -- Martin Harris Lead Software Engineer Cloudsoft Corporation Ltd www.cloudsoftcorp.com Mobile: +44 (0)7989 047-855
