On Tue, Jun 07, 2005 at 09:34:37PM -0400, Stephen Frost wrote: > > 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"? Anything involved in coordinating/managing the buildds. There is *always* some overhead involved; you may be able to minimize it, but you won't eliminate it completely. As far as I'm concerned you're welcome to try to streamline the coordination, but that's not something I'm personally involved in, so I don't imagine I'll be able to help you much. I would remind you that "find a way to divide up the centralized workload" is not a solution that lends itself to being engineered; both because the overhead of training and coordinating with inexperienced (or, well, inept) coordinators is often higher than just doing all the work yourself, and because there will always necessarily be a high trust/experience barrier to entry for certain aspects of this which limits the pool of candidates. > > - 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). There are a number of offers for alpha buildds that I'm tracking, most of them dating back to shortly after the Vancouver meeting. It's mostly a question of going through and figuring out which ones are suitable (i.e., which don't require us to arrange for shipping the hardware internationally or hunting down hosting in $country, which have a local contact that the project can trust, etc). > > - 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? Yes, it can. AFAIK. > > - 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? It's a logistics problem. > > 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. Ah, good. Then we know where to have the boxes shipped, then. ;) -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature