On Sat, 9 May 2009, Junio C Hamano wrote: > > I have been processing the patches in my "after 1.6.3" mailbox from the rc > freeze period and have already queued this one, but the re-integration of > four branches is taking a bit longer than usual. It takes too much time > to run tests (and as a part of my build procedure I do docs, too) for all > integration branches, and until they all pass tests on Debian5 (primary > development box) and Fedora9 (at k.org) I do not push the result out, so > it is a bit painful for me to replace a patch once a day's testing cycle > begins. Heh. I can attest from personal experience that if some test-sequence takes a couple of hours, and keeps you from making sane changes from the source, you'll eventually go mad. It was one of the reasons I absolutely hated working with CVS at transmeta - not only did the pre-checking tests take forever, but you effectively couldn't do anything else while they were running due to the whole "branches don't work". Now, at least you don't have _that_ issue, but if testing keeps you from doing the sane thing, you'll still end up having some of the same things happen. I've found that "make -j64 test" does fairly well, bringing the cost down to something reasonable. Some of the SVN tests seem to sometimes randomly fail when done in parallel (I've not tried to debug it, I assume it's either some SVN bug, or just the test infrastructure having some shared SVN central repo thing), but it happens rarely enough that even if you have to run it twice, it's still worth it. [ Side note: the success output of "make test" makes it almost impossible to debug the error cases when you do that "make -j64" thing. Sad. It would be good to have the tests that fail clearly say exactly what test failed, because when you run 64 tests at the same time, having "case 9" fail is almost totally useless information - test 9 of _which_ testsuite? ] I don't generally build docs, but they should run in parallel too, and at least your fedora build on kernel.org has a nice quad-core machine with lots of memory, so "-j8" or something is reasonable. Linus -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html