On Mon, Jun 06, 2005 at 02:12:00PM -0400, Stephen Frost wrote: > * Steve Langasek (vorlon@debian.org) wrote: > > Clone yourself and make yourself a slave to the buildds for 7 or 8 > > architectures, so that the release team doesn't have to. Neither the > Whoah, whoah, whoah, is this actually an option? Last I checked that > answer was 'no'. Well, I think there's still a moratorium on human cloning in the US, isn't there? > There seems to be a few different reasons for this, but one of the big > ones is wanna-build access, I believe. This is because of limitations of > the current wanna-build framework, which may have now been resolved? I wasn't necessarily referring to being buildd admins. The biggest time sink, AIUI, is keeping machines of reasonable power up and running, which ought to be the responsibility of the local admin (porters, presumably); it's not lack of w-b access which causes buildd starvation for those architectures that have that problem. Yes, I imagine the w-b infrastructure's lack of scalability was probably a factor in being choosy about what machines to accept as buildds, but there are certainly going to be other factors that scale linearly with the number of buildds, so I don't foresee the w-b admins ceasing to concern themselves with getting the most bang per buildd. But while everyone's fretting over whether the w-b admins will allow m68k buildd #15 to connect, we have the following architecture problems right now, in no particular order: - alpha: one buildd, able to keep up with current package volume; no spare buildd due to the principal candidate being inexplicably unbootable now (oh yeah, btw, the primary failed and was off-line for a day, a week before release); no porter machine available. - hppa: one buildd, keeps up with package volume, but no backup buildd and gdb seems to kill its kernel (yay); one porter machine. - sparc: one buildd which is not consistently able to keep up with the volume of incoming packages; no backup buildd, no additional porter machine. - s390: one buildd, which consistently cannot build gtk+2.0 because it only has 2GB of space available for builds and gtk+2.0's requirements have recently exceeded this; a second possible buildd is not yet hooked into w-b because of what appear to be administrative details. (two porter machines available, though.) - powerpc: one buildd that's getting long in the tooth; one porter machine. (obviously a readily available architecture, but that doesn't really help much if the only configured buildd is down and it takes a week to designate & configure a new one.) I have a really hard time believing that these architectures are blocked from adding a second buildd due to security or scalability concerns alone when at the same time we have roughly a dozen m68k buildds... 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, 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. 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; 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. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature