Hi Luca, thank you for your quick response and sharing your thoughts; they're helping me learn about our larger puzzle(s)...
Regarding the link to your slides -- Are they sponsored by GerritForge.com by any chance? I noticed its trademarked logo at bottom-left corner of many pages. In any case, regarding your comment about GitHub and Gerrit: Honestly, I'm not surprised at all that GitHub wouldn't be (at all) interested in integration with Gerrit. By design and from my observations, GitHub interactions happen via Fork + Pull Requests whereas Gerrit interactions happen via Branch + Push Change-Ids. They're inherently competing workflows -- GitHub pulls, Gerrit pushes. There are subtle differences, such as GitHub hiding (basic?) information that one may be interested in, e.g. email address of pull requester, and seemly selling the idea as simpler user experience. If one choose to compromise, or not compromise -- depending on your perspective -- such as: - Don't do GitHub pull requests, e.g. https://github.com/torvalds/linux/pull/17#issuecomment-5654674 - Creating a daemon that auto-closes GitHub pull requests, as Monty Taylor described to me for OpenStack, "Github does not allow a project to disable pull requests, so we also have a daemon which watches for pull requests in to the projects on github and auto-closes them with a message explaining how to submit changes to gerrit for review." https://groups.google.com/d/msg/repo-discuss/rersrCtdEiY/WW7xBYjL_iEJ - Or Creating Gerrit code that automatically imports GitHub pull requests Then it seems GitHub and equivalent such as Bitbucket, Gitorious, etc. become distribution-only mirrors, and we lose out on benefits of simpler user experience and social coding -- person-centric hub of git forks with associated pull/merge requests. Assuming that we all can mostly agree that our Simple goals are: 1. Merging code from one git into another git 2. Agreement between owners of both gits about the merge Aren't code review communication medium and topic-review life cycles, whether done via Gerrit, GitHub, and/or even basic e-mail mailing list, really a matter of personal taste and preferences among people in each (open source) software community? In our Jenkins open source community today in 2012, it appears that we've agreed to use GitHub Pull Requests until a better competing technology comes along, and motivating us to switch if/when needed in the future. Wouldn't you agree? :-) Thank you, Lloyd On Fri, Jun 1, 2012 at 1:45 AM, Luca Milanesio <luca.milane...@gmail.com>wrote: > Hi LLoyd, > > > > > As of today (May 31, 2012) I'm not foreseeing significant value > proposition nor positive return on investment in using Gerrit (in spite of > its features) in lively open source projects and communities such as our > Jenkins, especially when GitHub pull requests (distributed/forking) with > periodic reminders on this mailing list (centralization/federalization) are > working well for us. Of course, I could be missing a piece of a larger > puzzle, hence I'm asking you these questions: > > I think you are right in the sense you are missing the larger puzzle :-) > > There is a lot of sense behind Gerrit and a huge return of investment > using it with Jenkins. > (see http://www.slideshare.net/lucamilanesio/gerrit-code-review) > > It is not just the ability to "trigger a build" but the organisation of > the topic-review lifecycle. > IMHO GitHub plug-in is the right place to integrate Jenkins and GitHub > whilst Gerrit-Trigger has a different scope. > > Integration between Gerrit and GitHub would be cool, I proposed that last > year @GitTogether 2011 to the GitHub guys ... but apparently they were > neither interested nor excited on Gerrit and code-review. > > Luca. > >
