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

Answering a few replies at once, since this thread has wandered all over
the place.

On Tue, Nov 12, 2002 at 01:38:52PM +0000, Bastien Nocera wrote:
> On Tue, 2002-11-12 at 12:49, Kjartan Maraas wrote:
> > tir, 2002-11-12 kl. 11:37 skrev Michael Meeks:
> > > 	I think it's quite vital that we get developer consensus on at least
> > > one new sheriff. There was reluctance in eg. gtk+ to entertain the idea
> > > that even Jacob could commit build related fixes - we really need to try
> > > and attract some people that have the time, the interest, are doing loop
> > > builds and people respect enough[1] to allow them to poke their
> > > autotools.

You are expanding the issue here. We need a build sheriff or two or
three just like we had for GNOME 2.0, since build do break, particularly
in the lead up to releases as mistakes get made under pressure and
tiredness. If all modules participate in this or not is really another
question. I agree, Michael, that it would be nice to have everybody
giving the same permissions, but if that doesn't happen, then so be it.
Not having any sheriff at all would then be cutting off our noses to
spite our face.

> Who actually follows CVS HEAD for all the modules ? Somebody with a
> Tinderbox access would be good. (Ximian ok with letting someone with
> some access to theirs ?)

The second question is really besides the point. You need people who
have the ability (and do) build regularly from the appropriate CVS
modules and branches a lot. During the lead up to the 2.0.0 there were
multiple people like that. Further, as Michael points out, you need
people who can understand the autotools stuff (mostly) and read the code
to work out what caused the breakage and revert the minimal amount
necessary to fix it.

Looking at the Tinderbox results is one way to assure a build. Other
ways are building it yourself regularly and responding quickly when
people mention on IRC or in email that things aren't building -- then
the sheriff needs to go in, work out if it's a real build problem (which
about half of the ones I saw were not -- they were caused by problems on
people's system) and then fix it, if necessary. Surely the goal is
simply to keep the tree buildable during a time-sensitive phase of
development. How that is achieved is irrelevant.


The early bird may get the worm, but the second mouse gets the cheese.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]