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 benefits. > 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