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

Re: buildd administration

On Fri, Dec 09, 2005 at 10:11:12PM -0500, Daniel Jacobowitz wrote:
> The majority of "handling" logs is monkeywork - very easy, mostly
> automated.  The main jobs of the buildd admin are to

The job of the buildd admin is to make sure packages are built. Mostly
that's automated, which is great, which means the buildd admin's job is
mostly to keep the automation working.

>                                                       (A) provide a
> human sanity check on what's getting built successfully; I am and
> always have been somewhat dubious of the value of this, even when I was
> doing it; and (B) doing something about the failures.

By and large its the porters that need to do something about failures;
which is to say, working out the problem and uploading a fix. The
buildds job wrt failures is to make sure they're not caused by
brokenness in the build setup, which is one place the human sanity check
comes in. Likewise when the RMs are trying to coordinate transitions,
and packages need to not be autobuild on old libraries, or need to be

> What buildd.debian.org logs is the output of the sbuild runs.  We
> have great visibility into what _sbuild_ is doing.  But what the
> _buildd admin_ is doing is, by and large, taking care of the failures:

I don't think that's a valid way of splitting things up. The job is to
build packages; if that's being done mostly well, that's great. If the
other bits could be done better, well, fine.

> The current buildd admins don't seem to be very responsive about filing
> bugs for the failures; 

That's been the case for quite a while now from what I've seen; but OTOH,
there are plenty of FTBFS bugs that just don't get attention anyway. It's
also something competent porters can take over fairly trivially -- simply
by looking through the buildd.d.o logs and analysing the failures that
they can reproduce themselves.

> I don't think that the human step of signing the successful logs has
> any value nowadays.  

The value it has is that the key doesn't get put on a machine that's
running random scripts day-in/day-out. Delaying signing 'til the end of
the day gives you some chance to learn of problems that might apply to
successful builds too. Someone with a particular interest might like
to analyse this, but I don't think signing successful logs is much of
a problem.

> I don't have handy stats about the volume of
> mail produced by the buildd anymore, but voltaire's currently pumping
> out about eighty thousand lines a day over the last week and a half, if
> I'm looking at the right logs.

The number of lines isn't terribly interesting; you don't read build
logs like a book, you grep through them like an encyclopaedia at most.


Attachment: signature.asc
Description: Digital signature

Reply to: