Development/gerrit/FAQ

TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

• Wiki Home
• Development
• Design
• QA
• Events
• Documentation
• Website
• Localization
• Accessibility
• Marketing
• Diversity
• Wiki Help

• Overview
• Reporting Bugs
• How to build
• Code Overview
• Git Commands
• Debugging
• EasyHacks
• Release Plan
• FAQ
• Developers
• Extensions
• → Open Issues

This page was marked as inactive and is retained for historical reference. Either the page is no longer relevant or consensus on its purpose has become unclear. To revive discussion, seek broader input via a forum such as one of our mailing lists.

Why Gerrit, the FAQ

What is Gerrit?

Gerrit is a code review system, tightly integrated with git.

What do we expect to achieve with gerrit?

There are multiple objectives, in no particular order:

• Allow developers to pre-build commit on a variety of platform _before_ pushing them to master.
  In other words check and push rather than the current push and fix. (and yes there are way to do that in a 'feature/branch' kind of way)
• The fact that commit can be tested on their own, means that the need for the 'fastest' possible tinderbox is much less important. Today the reason speed is such a premium for these box is to avoid the 'domino' effect: someone push something that happen to break master... the long it takes the more other patch accumulate on a 'red' box, each of them has a chance to also break the build, but is less noticed because the breakage is hidden by the previous breakage... the list of people notified is getting longer and longer, and as a consequences people assume more and more that it must be someone elses bug. This phenomena was very obvious when the Windows build was taking 4 to 6 hours... windows spent days and weeks in a row in red... until a brave soul talked the thankless job of sorting all that out.
  With the gerrit model, the time to do a build is less important, and therefore even not-so-fast machine can be put to good use. In other words it scales better.
  Furthermore the granularity of the result is much more narrow and the nagging much more targeted.
• Gerrit has a very nice interface for interaction between developers, especially it allows reviewer to concisely state their remarks directly inline with the patch. it also allow the developers to trivially push a 'new version' of a given change. This make reviewing code much more practical... and given how hard it is to get Reviewer time, the easiest it is for the reviewer the better.
• It should be possible to semi-automate the application of patch submitted to the ML, ideally forward a patch from the mailing list to a dedicated mailbox -> the patch show up in gerrit... then review/verify/submit the change.. or ping someone else if the person that scrubbed the patch from the ML is not confident enough to 'commit' it
• Make the simple/triple review mechanism for release branch trivial: push a commit /for/<release-branch> and reviewer can just do +1 there... the reviewer that gives the last necessary review just puts +2 and clicks 'publish and submit' the change.
• Gerrit has a powerful query command line which allows for a convenient, customized way to query changes that get in. For example one could query to find all the changes that impact a given set of files, which would allow de-facto module maintainer to keep an eye on proposed change in their are of expertise... but that is just one example... Pretty much everything that can be done using the web interface can be done using command line... heck one could even write an emacs-mode front-end to gerrit... The plumbing is there, so if you do not like the web-porcelain, you can write your own.

What is the workflow with gerrit?

That is the big question, and that is why we asked you to 'play' with gerrit... The exact workflow, how far do we go with it are questions that require dev with different habits and requirement to tell us what is working for them and what is painful. With such feedback we can (1) improve the tooling (2) adjust the workflow (3) improve the documentation. Like everything else it won't be perfect for everything to everyone, but with feedback we can at least try to find the best compromise.

Why should I care, and why should I spend time testing/experimenting with it?

We will eventually switch the fdo git repo to read-only, which means that you will need to be registered in gerrit and put in the Committer Group there to be able to continue to push commits directly to master, and for that matter to do anything but 'read' the repos.

By experimenting with it, you can help us discover the kinks, pain-points or holes in the process. It is much easier to address these over some time while we can still make big changes without too much impact, rather than try to change on the fly a live production system.

Tips on gerrit use

Can I push my patch automatically to the right gerrit review branch?

See here.

Can I request some reviewers by default?

See here.

I get "Change-Id in commit messages are missing" when submitting

The git commit hooks are not correctly set up to add a Change-Id to your commit messages. Gerrit needs this in order to work.

First, correctly set up the commit hooks:

$ ./g -z

Second rebase your commit:

$ git rebase -i

And then submit it again:

$ ./logerrit submit