.webp)
Please give a warm welcome to Gerrit, the new guy working on Qt Creator! If you do not know him yet: He is the one adding text like
Change-Id: I8364167d5be3e7c361b192318b0bba7fb70d0f2f
Reviewed-on: http://codereview.qt.nokia.com/9
to commits in the Qt Creator git repo. That is, since last week we replaced our internal git server with a Gerrit based one, and are now using it for reviewing all commits.
Why that is worth a blog post? Well, using Gerrit is one of the first tangible results of Open Governance. Early on it became clear that the current informal ways of reviewing patches (discussions on IRC together with websites like pastebin.com, or e-mail) do not scale too well if you expect contributions from people with different technical knowledge, working in different time zones, and coming from different cultures. Therefore requirements for a code review tool were discussed on opengov@qt-labs.org. Different alternatives (I recall also Crucible) were evaluated, with Gerrit being the tool closest to our needs. Qt Creator is now the first project within Qt that is putting it into full use.
Soon you will be able to read and comment on incoming patches. You will be also able to submit patches for review after accepting the Qt Contributors Agreement. This is the "Contributor" role that Thiago has been describing in his blog post about Open Governance Roles and Responsibilities. The patches can then be accepted or rejected by someone with an "Approver" status, which will be the Nokia people working full time on Qt Creator, but also other people who contributed e.g. a plugin, and are willing to maintain it further. Finally, we'll also have an official maintainer for the whole of Qt Creator, the one who has the final say on things.
So, how does one work with Gerrit? It is deeply integrated with git, which makes it actually pretty easy to use (at least if you know git already). Submitting a patch for review is nothing more than a 'git push', and patches are automatically applied to the target git branch as soon as someone reviewed & submitted it. Also, fixing things in response to a review is just 'amending' the original commit in git, and pushing it again. The review itself usually happens on the website, which is actually quite responsive. You can see the diff on a per file basis and add in-line comments, and finally accept or reject the patch. You'll of course get notified via e-mail as soon as the status of a patch that you submitted, or that you are watching, has changed.
We only began using it last week, and are still in the phase of getting to know the tool for everyday use. We already found a couple of things that we would like to change: One of the top complaints is that on the website, there is no way to see the whole diff for a commit (in contrast to a file by file diff). Also, having to review commits one by one can be tedious if you are actually having a series of depending commits. We consider fixing these inside gerrit. Anyhow, all in all the start was pretty painless, and personally I have high hopes that the more formal process will help improving the overall code quality. E.g. the in-line comments help you to communicate also about minor things like coding style, and the explicit reviewing step avoids misunderstandings about whether a patch is actually ready to go.
Right now we are still using Gerrit only for Qt Creator, and are limiting availability to our development sites. The next steps planned for are opening up the website, allowing everyone to access it, and also adapting it for development of Qt and other projects. Currently we are focusing on hooking up bots for sanity checking before the actual human review takes place. For Qt we also need to run the continuous integration system for reviewed patches. We hope to be able to open up Gerrit sometime during next month. Meanwhile we still update the Qt Creator clone on gitorious , and in fact will continue to do so even after codereview.qt.nokia.com is available.
