* Steve Langasek (vorlon@debian.org) wrote: > 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? Eh, we're working on fixing that. > > 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: Getting the most bang per buildd is great; limiting the number of buildds because wanna-build doesn't scale sucks. What are the "other factors that scale linearly"? As has been told to me of late, better to ask for something than assume it's not available. Additionally, we need to make sure to place the resource drain on the right thing- there's some part of the buildd admin that depends on how many packages are uploaded to unstable and how frequently; the number of buildds which do the building of those packages is an orthogonal issue to that. > - 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. Ok, we need more alpha machines then. If nothing else then at *least* one for porters. Let's ask the debian-alpha list or debian-devel if someone's got a spare alpha they don't mind parting with. I can probably arrange hosting for it, if necessary (one way or another). > - hppa: one buildd, keeps up with package volume, but no backup buildd and > gdb seems to kill its kernel (yay); one porter machine. Well, at least we've got a porter machine, could that be turned into a buildd on relatively short notice if necessary? The gdb issue is something I certainly hope is being looked into or at least has been brought up to the LKML and debian-hppa folks. > - sparc: one buildd which is not consistently able to keep up with the > volume of incoming packages; no backup buildd, no additional porter > machine. Alright, we need more sparc systems, I'm working on getting arrangements for hosting at least one, I've got access to a few others as well. It sounded like there wasn't an issue getting sparc machines donated, so is this just a hosting problem? > - 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.) Then let's get another one up and running, do we need to go out and ask for donations? If we get donations, will they be turned down? That's been a historic problem that I'd really hate to see happen again. > 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... Got me on what the specific problem is, that's kind of what I'm trying to figure out... If we need more machines, or need hosting for them, then let's ask for it... Did I miss something where this was being asked for? Looking back through d-d-a I see that in one of the Release updates there was some talk about arm buildds but I didn't see much else wrt buildds back to at least November. Is this a new revelation due to the rather poor response to the Vancover proposal? > 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. Ehhh.. As a local admin for a pair of mips buildds I'd have to say that from my point of view, at least, maintaining them hasn't exactly required huge amounts of effort on my part. In fact, I'm pretty confident I could maintain quite a few more based on the current amount of time I spend on them. Perhaps the time you're referring to was time required by the buildd maintainer though, in which case perhaps we could look into developing tools to reduce the time required for buildd maintenance or add people when we need to add buildds. It feels like we're looking for excuses to not add buildds sometimes. :/ > 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. It seems like the reason the buildd admins' deal with this generally is because the problem is generally detected by one of them and then run down before a bug is filed and that puts a drain on the buildd admins. One possible solution to that would be to increase the number of buildd admins but another would be to perhaps make it more easily available what packages ended up in the 'maybe-failed' state for what architectures and maybe have it linked in with the porter lists or perhaps have a list which receieves such notices that interested porters could subscribe to. Of course, this has the difficulty that if it's not a buildd maintainer then if the issue is with the buildd itself it's harder to run down and fix... Thanks, Stephen
Attachment:
signature.asc
Description: Digital signature