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

Re: Canonical and Debian

On Tue, Jun 07, 2005 at 02:12:04AM -0700, Steve Langasek wrote:
> Oh, you'll also note that the traditional "slow" architectures (mips,
> mipsel, m68k, arm) aren't on this "problems" list.  That's because a *lot*
> of effort has been put into providing sufficient parallelization for each
> architecture; the ongoing cost to *maintain* these parallel buildds is
> higher than to maintain a single buildd,

Of course. Which is why we m68k people prefer to maintain our dozen
buildd machines with 7 people, rather than with just one, as the
mips(el) and arm buildd maintainers did, last I heard.

However, that is not the only reason. The fact that there are more of us
also means there are people readily available in case one of us goes on
vacation, or in case an extra build daemon needs to be set up. Provided
everyone has access everywhere (or at least "mostly everywhere"), it
also means that urgent problems can be dealt with more speedily, because
you don't have to hope that the one person who can fix it happens to be
readily available when the buildd chroot breaks completely. There are
more merits to a team-based approach; and while there most certainly are
downsides (e.g. the fact that you don't see everything, so it's harder
to see a pattern when many packages fail to build, and double effort may
be spent in that area), I don't think the problems outweigh the

> and given that each of arm, mips, and mipsel have had instances over
> the past year where they were short-handed, I don't know how realistic
> it is to expect that they'll stay caught up through etch's lifetime.

Well, see, I don't think it's a coincidence that m68k did not recently
have problems keeping up whereas the other "slow" architectures did.

As you know, m68k buildd maintenance has traditionally been a team-based
effort, while it has always been a one-man show on the other
architectures. Also, the group of "porters" and "buildd maintainers" is
roughly the same on m68k, whereas it's completely distinct on some of
the other architectures. Indeed, I was rather surprised to find out last
FOSDEM that some arm people were pretty unhappy with the fact that there
is no talk at all between the arm buildd maintainer and the people
looking after the arm port; then again, it could be that they inflated
their involvement in the arm port, and that in reality, there's actually
nobody looking after the arm port but the buildd maintainer -- I don't
know that, I'm not involved with ARM at all.

Anyhow, the point I'm trying to make is that while I'm not one to tell
other people how they should do what they're doing, it OTOH is not
really fair to say that maintaining a larger set of autobuilders isn't
really possible because it's not working out as it should on arm, mips,
and mipsel. Perhaps these architectures would be better off rethinking
the way they do things, going more towards an m68k-style team-based
effort rather than the current state of affairs.

> The second most significant area of concern, for me, is having people being
> proactive about dealing with per-architecture build failures.  There's no
> particular reason that should be the buildd admins' or the release team's
> area of responsibility, either;

I agree with you on the "release team" bit; however, I don't think it's
unfair to request that buildd admins handle build failures. If buildd
admins of some other architectures can't keep up because they're
handling all buildd hosts for 3 (or so) architectures, then the problem
isn't that they're asked to do things that aren't their responsability;
rather, the problem would be that they're trying to do more than they
can handle.

> all it requires is people who know what they're doing to file sensible
> bug reports without gratuitously duplicating efforts, and people who
> know the architectures to help the maintainers sort out bugs.

Well, IMNSHO, the first bit of this most certainly is the buildd
maintainer's responsability. I'l plead guilty if told that I'm not
always doing that properly as I should, but that doesn't change my
opinion on this matter.

Again, I don't think I'm in the right position to start telling other
people how they should do the work they're doing; everyone should do
what they think is best, as long as the work gets done, and if the
buildd maintainers of the other architectures feel that they can do
their job better by doing it all on themselves, then more power to them.

The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond

Attachment: signature.asc
Description: Digital signature

Reply to: