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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[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 >>>> >>>> >>
