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
