dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Git/gerrit migration status and next steps

Git/gerrit migration status and next steps

From: Torne Wuff <>
Date: Tue, 6 Sep 2011 15:40:28 +0100

Hi folks,

Apologies for not doing anything about this for a while; I have been
very busy with other stuff (and/or lazy). I want to sum up where we
are now and what the next steps are, and give people a chance to
comment on those next steps if needed.

Current status:

1) Gerrit is running on a temporary host at

2) Gerrit is serving up four git repositories "rockbox", "www",
"themesite" and "translate", which collectively contain the complete
history of Rockbox, in a "sensible" native git form (proper committer
names/emails, branches and tags present as git branches/tags). These
repositories are read-only as they are still mirroring svn and so
cannot accept commits. They are not being updated automatically at
present; I am doing it by hand on no particular schedule.

3) Gerrit is also serving up a repository "sandbox", which accepts
both direct pushes and code review uploads. The policies currently
forbid merges and patches are applied via cherrypick, not by merging.
I don't believe this is the best policy to have in place any more,
having experimented more with stuff, but I haven't yet changed it.

Next steps (pretty much in this order):

1) We need to move Gerrit and the repositories it's hosting onto our
infrastructure, at This in itself won't change
anything; it will still be a svn mirror and it won't immediately
replace the current git mirror that many of you are using (so any
local git branches you have won't break). Hopefully nobody objects to
this; I just need to coordinate it with the Swedes which I haven't had
time to do.

2) Set up automatic svn mirroring, the same as the current git mirror
has. At this point, anyone who's working using git should be able to
start using the new mirror for new work (their histories are not
compatible due to the author rewrite, so it's more tricky to switch
existing work over - talk to me if you want to do this, as I have some
thoughts on how it can be done sanely). The process for actually
submitting will be the same, though: you need to use git-svn to
dcommit to the svn repository.

3) Someone needs to work on the buildbot and website infrastructure so
that the buildbot can build based on git instead of svn, and the
website displays info from git instead of svn. We also probably want
to theme gerrit to match our website branding and put up a web-based
git history browser (gerrit does not provide this itself, but it can
link to one).

4) We write up policies and documentation on how to use git via
gerrit, though only two parts are crucial at this point: how to clone
the repositories, and how committers can commit directly to master.

5) We formally switch to git as our "master" repository. This means
svn will be disabled, write access for committers to git will be
enabled, and committers will need to register for Gerrit accounts and
give it their ssh keys to get access. At this point we don't need to
necessarily have any of the code review parts of Gerrit active; we
would just be using it as an access control system (a la gitosis).

6) Work out policies/documentation/etc for using the code review
system, for both committers and noncommitters, and enable this.

I hope those steps are reasonably clear and there's no argument about
what they should *be* - I realise there are still open
discussions/questions about policies (e.g. whether to allow merge
commits on master), but I'm not trying to resolve all of those right
now (we don't need to make any decisions about that until step 4).

So, as far as I can see it comes down to "do we want to use Gerrit at
all", here. I've heard a number of contributors (committers and
non-committers) approve of it, and I don't think there have been any
specific objections to the tool itself so far, only to the
configuration of the sandbox repository. The one downside I can see of
doing it this way is Gerrit will require that you have some kind of
OpenID account (a google account will do, but it doesn't care where
from; you can use any provider or run one on your own server) because
it does not implement its own login account system. We are not
intending to require committers go through code review, so the process
of creating a Gerrit account using OpenID and uploading your ssh keys
is the only interaction you will be *required* to have with Gerrit;
after you set it up, you can work with it the same as any other git

Comments? Questions?

Torne Wuff
Received on 2011-09-06

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy