Hi David,
Are there any conclusions on the apache pull request models, discussed
on the board list?
Obviously I'm fine with us following the model used by jclouds if that
is the conclusion for best practice.
However, I will greatly miss a couple of things:
* The big easy "merge" button is a pleasure to use; compared to the
CLI it reduces the risk of typos for the wrong branch name etc
* I can review + merge code with poor internet access
e.g. on a train where there's little chance of me pulling down the
branch locally and/or pushing it to a remote server, I can currently
click the merge button on the github web-page.
Aled
On 24/05/2014 18:36, David Nalley wrote:
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
