Distributed tinderboxing

[Ade Lovett]

On Sep 14, 2005, at 14:30 , Mark Linimon wrote:
> If you're really thinking expansively, you can always add another
> row for 'buildchain' in case someone ever wants to get so bold as to
> experiment with icc vs gcc.

Adding fields at a later date isn't so much of a problem.  What I'm  
trying to do right now is have a quick brainstorm session to see if  
there are any glaring errors or omissions, particularly in the way  
that the tables are cross-indexed, that would be cause pain down the  
road if they were to be fixed.

So far I haven't seen any fundamental flaws, so the next step would  
be to produce a schema and then use databases/p5-SQL-Translator to  
convert it into a pretty diagram to be able to visualize things a  
little better.

Once we're all in reasonable agreement on the schema, I'll then flesh  
out the rest of the design document, we can go over that, and then  
begin the coding process.

> Other topic.  Since my one attempt at a tinderbox is on a now-dead
> disk I can't go look myself.  Is there anything like the pointyhat
> scripts that takes each error log as it occurs, and reduces it to
> an error type?  Given that that happens, we can then think about
> adapting portsmon to learn from individual build boxes.  (Or, people
> can run their own copy of portsmon, I suppose).

The cleanest way I can think of doing this would be to add in some  
routines to portbuild.  Around line 467 of that file is where the  
error logs are written out.  It would be trivial to add some code  
there akin to the pointyhat scripts to post-process the log, and  
write something out (either to a separate file, at the top of the  
error log, or possibly in the database itself) which could then be  
picked up by the PHP frontend.

-aDe