GerritHub.io was launched 2 years ago.
Learnings, problems and new ideas on how to improve the GitHub to Gerrit plugin and hints on Gerrit scalability and replication.
2. 2 .io
About Luca
• Luca Milanesio
Co-founder of GerritForge
• over 20 years of experience
in Agile Development
SCM and ALM worldwide
• Contributor to Jenkins
since 2007 (and previously Hudson)
• Git SCM mentor
for the Enterprise since 2009
• Contributor to Gerrit Code Review community since 2011
6. 6 .io
There are two fundamental problems with single-
patch review systems:
1. They encourage lumping at-best-weakly-related
changes together.
2. They encourage you to hide your history.
[http://bit.ly/1hhQkcA]
The pull-request system looks like an incredible
easy way to contribute to any project hosted on
Github [but] doing any proper and useful
contribution to a software is never done right the
first time.
But as a software maintainer you'll end up with
pull-request you'll never get finished unless you
wrap things up yourself.
[http://bit.ly/1o7HIb6]
A big advantage in Github's favor is the number of
developers that are familiar with it compared to
Gerrit.
Gerrit can be popular with Git power-users, but
friction-free use of it requires intermediate or
advanced git knowledge, and tolerance of a steep
learning curve.
[http://bit.ly/1cJV8IJ]
I have no problem with people using github as a
hosting site, but in order for *me* to pull from
github, you need to
(a) make a real pull request […]: real explanation,
proper email addresses, proper shortlog, and
proper diffstat.
(b) since github identities are random, I expect
the pull request to be a signed tag
[http://bit.ly/1iONQ4L]
27. 27 .io
Problem #4 - Options
• Quotas for FREE use
• Charge for private Projects / Teams
• Charge for Commercial use
• Charge for Gerrit private virtual hosting