[coreboot] [ANN] New code repository and development workflow

Gregg Levine gregg.drwho8 at gmail.com
Mon Jun 6 00:17:10 CEST 2011

On Sun, Jun 5, 2011 at 4:48 PM, Patrick Georgi <patrick at georgi-clan.de> wrote:
> 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/
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot

I have one. What would prompt this to happen?
root at jimkirk2:/usr/src/lobos# git clone http://review.coreboot.org/p/coreboot
Initialized empty Git repository in /usr/src/lobos/coreboot/.git/
fatal: http://review.coreboot.org/p/coreboot/info/refs download error
- The requested URL returned error: 403
root at jimkirk2:/usr/src/lobos#

That's from my first efforts to clone the recently configured repository.

Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."

More information about the coreboot mailing list