[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bits (Nybbles?) from the Vancouver release team meeting

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

Reply to: