|
Right now only one server is running opencores,
although a dual processor machine, it does not have enough performance to run
regressions or build tools all the time. So this is restricted to once daily.
Maybe we'll put a second machine in place when there are more
developers.
Anyway I like the idea of sending an email to
people that submitted patches since last successful build. Will have a closer
look at Tinderbox.
regards,
Damjan
----- Original Message -----
Sent: Thursday, April 10, 2003 5:55
PM
Subject: Re: [openrisc] Fw: OR1K
Automated Testing System - gdb
Damjan Lampret wrote:
FYI this was on Tuesday. I haven't checked yesterday or today, maybe
everything is OK today.
I had noticed this build error
yesterday morning when I woke up (Pacific Time). (I had thought I had
checked in all my changes, but I had missed one file.) Anyway, with that
last file checked in, it seems to be fixed now. Sorry about
that.
On a negative note, the uclinux test is now failing, presumably
due to my UART simulation changes. Apparently the serial driver used
during uclinux booting is different than the one used after the kernel starts,
since only the former successfully generates output. I don't think I'll
have any time to debug this in the near future, so I will probably just back
out my change to 16450.c.
By the way, should ATS error messages go directly to openrisc mailing list
(if there is a problem, a very long email is sent). Right now ATS emails are
sent only to me.
I think that if you send that much traffic to such a
large list that a lot of people will complain/unsubscribe. You could
create a mail alias for the or1k maintainers and send the mail just to that
list.
If someone wanted to be really ambitious, we could use the Tinderbox automated
build system as a wrapper around the ATS scripts. Tinderbox is
integrated with CVS and will only send email to those people that could be
responsible for a build error, i.e. those that checked in between the last
good build and a subsequent failed build. It also has a lot of other
nice features, i.e. you can see a listing of the new checkins made that
affected a particular build, it will associate compiler warnings with a
particular developer. Here's an
example of Tinderbox in action.
While Tinderbox is probably
overkill given the relatively modest size of the development group, it would
be nice to migrate one feature from Tinderbox to ATS: continuous builds (or at
least more than one build a day). I don't know if you have the CPU
cycles available, but if you do, it would be great if ATS builds could be run
two or three times a day.
-Scott
|