Migrating to Gerrit for patch tracking and code review
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
- 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
- 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
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/.
- 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
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