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/