Re: state of the buildbot

[Iago Toral Quiroga <itoral igalia com>]

Hi Frederic!,

good points all of them! I comment below.

El mié, 08-10-2008 a las 22:52 +0200, Frederic Peters escribió:
> Hello all,
> 
> The three slaves are now running smoothly, some build failures could
> sure be fixed[1], automatically even for some, and that is part of
> this message, how do we improve the system now?
> 
>  - the coverage reports, they were really nice but they need the build
>    slave to have a webserver to publish them; perhaps that step could
>    be made optional, and we would mandate one of the build slaves to
>    be the "coverage reports" slave?

Yes, I think making it optional is ok. BTW, another option, I think
Thomas mentioned it some time ago, would be that slaves would send the
coverage reports to the master, which would be the only one running a
webserver. 

>  - current setup requires an attentive eye (or more) to catch
>    regressions; it would be great to have per-module and per-slave
>    feeds, listing build regressions (per-slave is easy, that is just a
>    module who failed, while building the previous time; per-module may
>    be more difficult, as we could want the regression to happen in
>    more than half the slaves failed before assuming it is module
>    regression, especially if we want to hook module regressions to IRC
>    nagging).

The per-module approach is a very good idea, if that works reasonably
well then we could think about IRC notifications seriously.

>  - way less important but nice would be to have the build master
>    reload its configuration (list of slaves, list of modules) without
>    having to be restarted (I am sure it is almost there but I didn't
>    have the time to finish this).

Actually this is very interesting feature imho, it is a pain to do it
manually, although now it is not as annoying as it was before.

>  - another nice thing would be to have "administrative tasks" that
>    could be sent by the master, things like updating modulesets or
>    removing a module directory.

I guess you mean a web interface to do this kind of maintenance tasks.
That would be good to have, sure.

>  - particularly useful at the moment would be the handling of more
>    than a single moduleset by a single master; so it could send 2.26
>    jobs to all slaves but one, keeping it at 2.24 as long as necessary
>    (2.24.1 at least, maybe 2.24.2).  Another use would be for the
>    release team to tell a slave to build the moduleset they
>    release[2].
> 

Yeah, this would be interesting although I guess this would not be so
easy to implement (just guessing).

> 
> If anybody suddenly gets lots of free time, that is a nice list of
> ideas to spend it :)
> 

I'll add a couple of extra points:

Implement the jhbuild bot stop command (I'll check this myself) . Also,
it would be nice if we could store the logs in a file, right now I think
they are sent to stdout directly. And also, it would be nice to have a
way to automatically clean old logs (from twisted and buildbot).

Iago