Migrating to Gerrit for patch tracking and code review

Sam Thursfield sam.thursfield at codethink.co.uk
Fri Feb 6 17:19:57 GMT 2015

A group of people discussed patch trackers and Git servers at the
Baserock public meetup on 5th February 2015.

We agreed the following:

- we want to use Gerrit for patch tracking and review for the various
   Baserock tools we develop. This will replace the mailing list patch
   review we currently do. We didn't discuss whether we'll actually
   discourage people who don't want to use Gerrit from continuing to
   mail their patches to baserock-dev.

- we want to allow downstream users of Baserock to use any Git servers
   and patch tracker they want, including proprietary ones.

- we no longer think the concept of a 'Baserock Trove' is useful and
   will try to avoid referring to 'Trove'. Instead, we'll talk about the
   component parts: the Gitano git server, the built artifact cache, the
   Git query part of morph-cache-server (which exists to make current
   versions of Morph faster at calculating the build graph) and the Lorry
   mirroring service. These all need to be 'horizontally scalable', which
   means making it possible to spread the work they do across multiple

We want to do the following to get gerrit.baserock.org usable for
Baserock developers:

- import all baserock/baserock repos that are not marked 'Obsolete', and
   baserock/local-config/lorries/ into gerrit.baserock.org. This is best
   done using lorry-controller so they are kept up to date.

- set up automated backups of gerrit.baserock.org and our MariaDB

- test that restoring from these backups into a new Gerrit instance
   deployed from infrastructure.git produces a working copy of

- discover the best way to get audit logs (who changed a rule and when)
   from Gerrit, and make sure we are recording these logs somewhere safe
   and accessible.

- set up an appropriate ruleset for Gerrit

- set up replication from gerrit.baserock.org to git.baserock.org using
   the gerrit-replication plugin

- disable push access to git.baserock.org/baserock/* for all users
   except gerrit

I hope to do most of this work in the next few weeks. Disabling push
access to the baserock/ repos hosted at git.baserock.org will be done
with a couple of days notice, announced to this list. After this time,
everyone will need to push branches to gerrit.baserock.org instead.

We discussed the Gerrit ruleset a bit. Unlike the current
git.baserock.org instance where only certain people can push, we want to
enable push access for anyone who registers a gerrit.baserock.org

We will aim to have 3 groups set up for each repository: Developers,
Reviewers and Mergers. Developers will be allowed to push. Reviewers
will be allowed to give a +1 or -1 code review. Both of these groups
will be open to any registered Gerrit user, and people will be able to
add themselves to these groups. (Thinking about this now, perhaps
membership could be automatic -- seems a bit of a faff to have to enroll
yourself manually in each one. We'll see how it goes). Hopefully
developers will be limited to pushing branches in a personal namespace
(so I can only push to samthursfield/foo, not to 'foo'). Mergers will be
able to merge branches to non-personal branches like 'master' or

I'm not quite sure if we'll need to keep typing 'baserock/' in front of
all our branches -- we might be able to avoid it if we don't mirror
personal branches in git.baserock.org. This and other details of the
ruleset will need some ironing out once the Gerrit is up and running

The initial set of Mergers will probably come from people who are in the
baserock-writers group on git.baserock.org, and we'll stick with the
policy of requiring two +1s on the mailing list from other Mergers to
enroll new people in the Mergers group.

The delta/ repos will continue to be hosted at git.baserock.org and
access will be managed with the same policy as before. We explicitly
want to encourage developers making branches of upstream projects. If we
find that we are making lots of changes to an upstream project that are
not accepted by the upstream developers we will fork the project and
start to do our own code review in gerrit.baserock.org.

What we do not want to see is patches for GCC or GStreamer or such like
going through Baserock's code review process -- patches for GCC should
go to <http://gcc.gnu.org/bugzilla>, patches for GStreamer should go to
<http://bugzilla.gnome.org>, etc. You can send a link to the upstream
review request to the baserock-dev list if you think it's relevant, of
course. Development branches of delta/* repos can be hosted in any Git
server, including free ones like Github. For the Baserock reference
systems that we release, we'll continue to require that only repos
hosted at git.baserock.org are used.

This means we'll have to continue caring about who can push to delta/ a 
bit. I imagine any new Mergers for definitions.git should get a 
git.baserock.org Gitano account at the same time so they can push to delta/.

Future plans:

- look at retiring people from the Mergers group if they have been
   inactive for a long period of time.

- investigate whether Gerrit can share its backing store with Gitano,
   which would allow us to merge the backing stores of git.baserock.org
   and gerrit.baserock.org.

Comments on this approach are welcome, especially if you have ideas for
making it easier. :)


Sam Thursfield, Codethink Ltd.
Office telephone: +44 161 236 5575

More information about the baserock-dev mailing list