[Kerncomp-devel] Re: [ANNOUNCE] Automated Kernel Build Regression Testing

[Ian W. <ia...@ge...>]

On Sat, May 14, 2005 at 06:17:18PM +0200, Jan Dittmer wrote:
> What I plan to implement, hopefully till next weekend, is a system
> which discovers new kernel versions and builds a table of
> kernel/version/arch triplets that want to be tested.

Ok, that's good.  However, I would say the most important thing for
*us* is application of patches and building from a git tree every
night.  Currently the rate of change in the git tree isn't really like
what the old bitkeeper trees was, but I'm sure it will get there.
This has really what kerncomp was used for from the start, it
originated right at the time IA64 was moving from being kept out of
tree to being merged into mainline.

For people who aren't trying to maintain out of tree patches this
really isn't important.  

> Against these versions any number of tests can run: compile, run
> time test, whatever, ... and report the results back, without much
> of formal requirements.  Basically a big storage of test
> results. Would that work out for you?

It sounds like it would; I guess the devil is in the details :)
 
> ... and write git-SELECT to search through them? :) Really sql has
> lots of advantages when your store even slightly more
> complex/relational things.

Personally, I'd really need to be conviced on the need of database
here.  We do all our builds on a big machine that is largly unused
overnight, and can then simply rsync the results over to the
webserver.  If I want to put a status as to why the build failed, I
just add it in the summary.log file and re-rsync.  If I screw
something up, I just delete the subdirectory.  Everything is kept in
order via standard unix permissions.  If I need to sort through the
output, I use sed and awk.  We just bzip the files to archive them (we
could use rzip across all of the files if space was really an issue).

-i