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

Thomas Gstädtner thomas at gstaedtner.net
Mon Jun 6 00:24:57 CEST 2011


On Mon, Jun 6, 2011 at 00:17, Gregg Levine <gregg.drwho8 at gmail.com> wrote:
> 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
>>
>
> Hello!
> 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."
>

That's odd.
First of all: worksforme(tm).
This message should only appear when you do a "git init", not for a "git clone"
Maybe the path "/usr/src/lobos/coreboot" already exists? Highly
unlikely that this would cause this behavior, but if so, try to remove
the coreboot dir or chose another destination.




More information about the coreboot mailing list