On Mon, Jun 6, 2011 at 00:17, Gregg Levine <[email protected]> wrote: > On Sun, Jun 5, 2011 at 4:48 PM, Patrick Georgi <[email protected]> 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: [email protected] >> 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 [email protected] > "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. -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
