Re: Minutes x2 for release team 2002-10-30 and 2002-11-06

[Dan Mills <thunder ximian com>]

On Mon, 2002-11-11 at 18:53, Malcolm Tredinnick wrote:
> On Mon, Nov 11, 2002 at 08:28:17PM +0000, Telsa Gwynne wrote:
> [...]
> > Minutes for Gnome 2 release team meeting 2002-10-30
> > ===================================================
> [...]
> >   * Build sheriff needed
> > 
> >   Dan Mills (<v_thunder> on IRC) has been doing this on an
> >   unofficial basis. He hasn't been reverting commits that break
> >   things, but he has been mailing module maintainers when the build
> >   breaks. 
> 
> Based on some experiences leading up to GNOME 2.0.0, could I suggest
> that we have multiple build sheriffs this time around. The problem is
> that even Jacob had to sleep sometimes and we would often be in a
> position of a commit breaking the build and then having to stall for 12
> or 18 hours to get either release team approval to fix it (again
> timezones interfered) or wait until the build sheriff woke up.

Well, it seems that I chose a great time to take a one-week vacation:
right before this thread.

Nevertheless, I'll add my $.02 after the fact:

I can't really say beforehand how well multiple build sheriffs will be
able to work together, but my guess is we want to keep the number small
in any case.  Also, if necessary near release dates, I can be woken up. 
It won't be the first time I lose sleep over a build ;)

I am currently working on vastly improving (imo) the logs tinderbox
produces, but it might take me some time.  It is a non-trivial amount of
work, given the current set-up.  I think that once that work is done
more people will be able to easily spot where and why build errors are
happening.  Hopefully this will mean maintainers will take the time to
check the log if the build dies on their module.

I'd propose having tinder automatically send email to the maintainer of
the dying module as well.  With some checks in place to avoid repeating
the same message, this could provide for an even quicker turnaround.

Of course, as was mentioned before, the quickest way of all is never
making any mistakes :-)

Cheers,
-Dan