At the beginning of May 2013 first European Gerrit Hackathon took place in London. It was quite some time ago (more then a month), but in my opinion it is always good to have summary afterwards.
So, as I mentioned it was first Gerrit Hackathon in Europe, organized by Luca Milanessio in London and kindly hosted by ITHR Consulting. Twelve participants come from variety of countries and industry areas to work together on Gerrit. We had three really productive days full with many interesting discussions, about project future and new improvements, and code sessions with interactive feedback loop (no delays or time zone differences) … just focus on task at hand and proper solution for it 😉
I think that main topic and killer feature of this hackathon was inline editing driven by Marting Fick (Qualcomm), Edwin Kempin (SAP) and Dave Borowitz (Google). As far as I know this is already available in current master branch (2.8-SNAPSHOT) and allow user edit its commit in the browser. By ‘edit’ I really mean editing files in browser and ‘commiting’ them back (of course this will create new patch set). With this functionality you can easily and quickly fix typos/white spaces/comments in code and commit message without fetching given change locally, amending and pushing back. This could save tons of time… but of course it could hit you very hard if you are not careful enough.
Next topic was statistics and some ground work around generating reports from Gerrit. AFAIR Edwin Kempin, David Pursehouse (Sony Mobile), Gustaf Lundh (Sony Mobile) and Emanuele Zattin (Switch Gears) had some discussions how stats can be collected and accessed. AFAIR there was also a (POC (?)) patch send for review that was adding REST service with some basic statistics.
I think that most of Gerrit administrators and contributors doesn’t know what term ‘capability’ means in Gerrit environment. So, ‘capability’ is ‘type of permission’ eg. ‘forge autor’ or ‘label verified’ are core Gerrit capabilities. Unfortunately plugins cannot contribute their own specific capability, this is really painful in case of replication plugin. Which uses ‘start-replicate’ capability defined in core (but not used there) to grant users permission to execute replication. Looks like this awkward situation was somehow painful for David Ostrovsky (independent) since he started working on this topic (together with Dave Borowitz). I know that there was some patches send for review and I hope that in 2.8-SNAPSHOT this problem is sorted out. Also this means that other plugins can contribute theirs own capability and extend this way Gerrit access rights.
There was also continuation of (never ending story) Gerrit multi-master configuration. As usually this topic was brought by Luca Milanesio and Deniz Türkoglu (Spotify) 😉
Deniz Türkoglu during hackathon was also working on ‘blame plugin’ for Gerrit. The idea is to send mails to code-line-authors when somebody changes specific line or code section. AFAIR there was serious problems with Gerrit API that disallow accessing DB out of RequestSope. Hope that this problem will be solved in nearest future and we could enjoy this plugin in community 😉
As we are in ‘build system’ topic… during hackathon decision was made that Gerrit will give a try to Buck (ant-like, developed in Facebook, similar to Google’s) build system. In Gerrit 2.8 you will not find pom.xml but BUCK file, this transition should make Gerrit development and releasing easier. Gerrit’s Buck srripts can generate Eclipse project configuration files, also use maven repositories for fetching dependencies. I can confirm that with without tons of Maven projects in Eclipse, IDE is more responsible, GWT development is faster and easier… also build time is shorter … but … there are the down sides as well. Buck is only supporting unix like systems and it is not (yet :)) an industry standard.
OK, I think thats it… I had a great time during this event also during my morning runs in Kensington Gardens. Hope to visit London again. See you all on next Gerrit Hackathon/User Summit 😉
In case of BUCK other interesting solution is Grade. It works perfectly well on Linux, Windows and Mac. It can generate idea and eclipse files and also it’s quite popular and there are tons of plugins for it (if it is not good enough grade can use maven plugins).
But anyway, really interesting post.
There was huge discussion about and Gradle was examined but finally, BUCK wins…
BTW Google has chosen Gradle as standard for Android builds (despite Facebook proposing BUCK for building apps)
Thanks for taking the time to write this article, it’s very useful to have some insights and documentation about the decisions (about Buck for instance).
@Luca Milanesio: Are you sure the Google decision to use Gradle applies to Android? My understanding is, the decision applies only to the Android SDK (rather than the entire platform) and that AOSP will continue to use a “make” based build system.