Gerrit joined the Qt Creator project!

Published Monday May 23rd, 2011
7 Comments on Gerrit joined the Qt Creator project!
Posted in Contributors, Git, Open Governance, QtCreator, Uncategorized

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

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, 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 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 is available.

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Contributors, Git, Open Governance, QtCreator, Uncategorized


Victor Ostashevsky says:

Thanks for information!

One minor thing: Qt Creator clone on gitorious link doesn’t point to Gitorious 🙂

ary says:

1) Does the system also include regular automatic evaluation of unit tests (and integration with git bisect to automatically mark offending commits during the review phase)?

2) What other technical quality assurance functionality will the Open Governance infrastructure provide to help the maintainers ensure that the code will remain stable?

3) Will you enforce QA-motivated strict global commit policies, like e.g…
– only accept commits which pass all existing unit tests
– only accept new-functionality-adding commits if they implement corresponding unit tests for the functionality they add …?
(In my opinion, you should…)
Or will such decisions be up the maintainer of the respective module?

That is great news, we have been using Gerrit for quite some time at Kitware and it has been effective. There are several additional features we are working on getting in to deal with CDash@Home integration (for testing new commits) and topic branch support. I will keep an eye out for when you make your Gerrit installation public, while there are some rough edges I think Gerrit has been a step forward for our projects that have begun using it.

There are quite a few people and organizations interested in support for topic branches, topic level review, etc.

Kai Köhne says:

@ary: Actually Qt Creator was selected as the pilot because we have neither a staging system, nor an extensive autotest suite 🙂 While I see the value of this for a library like Qt, we can keep Qt Creator development much more agile. The only thing that we currently have in place are some simple (static) checks that e.g. prevent anyone to check in a multi-megabyte coredump file.

Now as mentioned in the blog we are also thinking about bots that try to compile a patch, and indicate success or failure, even before a human has a look. This is inspired by what webkit does. These checks will be just a hint though, because they might be false positives or negatives.

Finally, for Qt the already existing CI staging system will do a complete recompile on all platforms. Currently, it also runs all autotests (one might restrict this further though). This takes a long time, and therefore won’t be done for each individual commit, but for a whole bunch of commits. The result is however authorative: No commit that breaks the autotests will be allowed to pass.

kkoehne says:

@Marcus: Yeah, I just saw the discussions about topic branches & review on the gerrit mailing list: ! Hope to see this improved soon!

Kai Köhne says:

@Victor: Fixed, thanks

Commenting closed.

Get started today with Qt Download now