On Tue, 2005-08-09 at 12:54 +0200, Laurent GUERBY wrote: > On Tue, 2005-08-09 at 11:02 +0200, Sebastian Pop wrote: > > I'm proposing to automate gcc's bootstrap & regtest: for each mail > > sent to [EMAIL PROTECTED], if 'From' is in gcc-developpers and 'body' > > contains a patch against some branch (ie. if it fails to apply to a > > branch, just drop it and warn the user), enqueue it for validation. > > The main server can be some script that monitors the availability of > > cpu ressources and that distributes the patches for validation. The > > answer can be a mail with just "passed witout regressions", or "patch > > causes regressions: <list of testcases that failed>". > > > > Bandwidth usage: size of incoming mail patch + size of answer + "cvs > > update -dP" every morning. > > Looks good. I think it would be slightly more secure to have people > commit the patch with a unique name in some access-controlled CVS > (either some subdir of the GCC one or a new local one) than relying on > email "From" fields at the cost of minor inconvenience. >
Why bother? Nobody forges mails to *test patches*. What does it buy you? Let's say you could buffer overflow the patch program with a specially crafted patch. Now you have access to ........ GCC source code (I assume these things are properly segregated from your internal network)! SuSE, for example, has an automatic patch tester that just goes by from address. If i was required to do cvs commits somewhere else to test a patch, I wouldn't bother, and i doubt most people would either, even though you just consider it a "minor inconvenience". It's more inconvenience than the auto-tester is probably worth. > Also for the cvs update, I assume one of the machine will do an > rsync of the whole CVS repository to factor external bandwidth cost > and it enables some binary search stuff at no external bandwidth cost. SVN rsync is very cheap.
