Dear coreboot developers, stakeholders, and enthusiasts,
I'm glad to be able to announce that we moved the repository
infrastructure to git and gerrit, with jenkins as supporting facility.
This was done with the goal of improving the development workflow,
meaning less overhead for developers when managing the patch queue. This
should lead to losing fewer patch submissions.
So far we used patchwork[1], but it's more maintenance work than
practical given that it requires manual handling of patches that don't
match the commit diff, and of patches that went through multiple
iterations.
While it improved the visibility of patches (and I'm thankful for that),
it still posed a higher than necessary barrier to patch review.
Gerrit[2] is a code review utility developed by Google which uses the
distributed properties of git to provide a seamless path for patches
from submission to commit.
For this, git[3] is used: Gerrit uses its ability to create and tear
down branches as necessary to push every contribution into its own
branch. This way it's already "tracked" by the version control system
without influencing the master branch.
The use of git also plays well into the desire of several coreboot
contributors to switch from svn to git.
In addition to these changes, we also moved the build bot from our own
custom build variant to a more standard Jenkins[4] installation. In
addition to building commits after they are integrated on the master
branch ("trunk" in SVN terminology), it's also configured to build patch
submissions on gerrit as they come in. That way there's automated
feedback on a patch before spending time on it.
All this means that the coreboot development workflow changes
considerably:
1. New SCM
You will need git, so install it from your usual software distribution
channels.
For patch submission a gerrit account is necessary. You can register it
on http://review.coreboot.org. With the account you can also review
patches. The ability to merge patches to mainline will be granted by
admins.
ssh public keys are used for authentication. You can register them with
gerrit in your user preferences at http://review.coreboot.org/#settings
when logged in.
Gerrit requires that the commit message contains Change-Id: lines. "make
gitconfig" inside a coreboot checkout installs a commit message handler
which takes care of this.
The committer address must match an email address that is registered
with your gerrit acccount. Again these can be configured in gerrit user
preferences.
Fetching anonymously: git clone http://review.coreboot.org/p/coreboot
Fetching authenticated: git clone
ssh://<username>@review.coreboot.org:29418/coreboot
2. New patch submission process
Develop "as usual" in git, and commit freely.
When you're ready to submit patches, push them with
git push origin HEAD:refs/for/master
This will tell gerrit which branch your commits are for (master) and it
will create internal branches for each commit you pushed, making them
separate changesets. If you push a number of commits at once, they're
properly linked as "dependencies", so people (and tools like gerrit and
jenkins) are aware about prerequisites.
For automating some aspects of patch submission, see the last paragraph
of http://review.coreboot.org/Documentation/user-upload.html#push_create
We will also document more of making live easier at
http://www.coreboot.org/Git as best practices are established.
3. New patch review process
The main interface to do patch reviews is the gerrit webapp at
http://review.coreboot.org. For those who tend to avoid web apps,
there's the option of controlling gerrit via ssh. Detailed information
on that will be posted at http://www.coreboot.org/Git.
There's no real workflow defined around this interface yet because it
seems to be an unpopular choice as _User_ Interface. This means, we'll
have to develop our own.
4. Mail notification
Mail notification to the mailing list is implemented from scratch. Right
now it only reports on new patch submissions and on patches merged into
the master branch. More events might/will follow in future, and we will
certainly tweak the ad-hoc messages and formatting some more.
Questions? Comments? Praise? Flames?
Patrick
[1] http://ozlabs.org/~jk/projects/patchwork
[2] http://gerrit.googlecode.com
[3] http://git-scm.com/
[4] http://jenkins-ci.org/
