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

[Steve McIntyre <steve@einval.com>]

Hey Steve,

Steve Langasek wrote:
>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.

The scalability issue can be solved, either with connection caching or
maybe some other way. The security argument seems a little thin, to be
honest - we already have binaries built and uploaded from developers'
machines all over the world. So long as an arch team can communicate
effectively, I'd push for a greater number of buildds for better
resiliency.

>> 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.

OK, cool. I await the results of the changes with interest. :-)

Thanks,
-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
Welcome my son, welcome to the machine.