On Sun, Jun 5, 2011 at 4:48 PM, Patrick Georgi <patr...@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@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >
Hello! I have one. What would prompt this to happen? root@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@jimkirk2:/usr/src/lobos# That's from my first efforts to clone the recently configured repository. ----- Gregg C Levine gregg.drw...@gmail.com "This signature fought the Time Wars, time and again." -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot