Hi Steve, On Mon, Mar 14, 2005 at 11:41:59AM +0000, Steve McIntyre wrote: > >- the release architecture must have N+1 buildds where N is the number > > required to keep up with the volume of uploaded packages > >- the value of N above must not be > 2 > When you say "N+1" buildds for a release architecture, do you mean > _exactly_ N+1, or _at least_ N+1? At least; although, there are some concerns about plugging too many machines into wanna-build for each arch, both for scalability reasons (hopefully addressed once we have connection caching support on newraff) and, I suspect, for security reasons (since the thinner we spread our autobuilder network, the more danger there is, statistically, of a trojan being injected), so it may be that in most cases no more than N+1 would actually be allowed at any one time. > Also, a common complaint I've heard recently is that several of the > SCC architecture buildd problems were being caused by lack of > time. Not machines, not offered effort, but lack of time to do buildd > setup/maintenance work by central buildd admins. Note: I'm NOT > attributing this to malice or incompetence - people need to sleep and > have some semblance of a life outside Debian, after all! m68k has > shown that a larger team of buildd admins and machines can work > effectively, allowing the least powerful of our architectures to keep > up admirably well in recent months. Is the plan for etch to still > continue to run with centrally-controlled buildds, or will it be > opened up? The partial answer I was given for this was to wait and see how well ftp-master scales once connection caching is in place, before committing to giving porters free reign to plug new autobuilders into the network. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature