On Fri, Apr 26, 2013 at 02:49:05PM +0200, Hector Oron wrote: > 2013/4/12 Raphael Hertzog <hertzog@debian.org>: > > OffensiveSecurity owns a Calxeda Highbank cluster of ARM machines[1] and is > > willing to dedicate one of the nodes to Debian. > Thanks, that is a very kind offer and with ARM hat on, we cannot > reject the offer, it makes it very interesting as a playground > machine. However, let me make some points here: > * ARM porters hat: It is very interesting machine, and very useful to > start experimenting with it as Debian is seeking for a full Calxeda > chassis. > * DSA hat: The machine shall not be a debian.org machine, so DSA could > export accounts if requested. Why in the world not? I'm sure there's no requirement for debian.org machines to be hardware owned by Debian. The s390 porter machines/buildds certainly aren't; I don't see why this machine would necessarily *not* be a d.o machine managed by DSA. Of course if it's going to be DSA-administered, I'm sure DSA would want exclusive admin rights on the machine; but that's just common sense, and AIUI not excluded by the offer. > * Buildd hat: The machine shall not be used to run buildd software to > build official packages. Again, why not? As far as I can see, this would be the single best use that a Highbank node could be put to by the project. As <http://release.debian.org/wheezy/arch_qualify.html> shows, we have quite a few more buildds deployed for both armel and armhf than is optimal - and in the case of armhf, we have so many that we're technically exceeding the release requirements. A single Highbank node could replace at least 2 of the fastest buildds we currently have in production... and probably somewhere between 4 and 8 of the slow ones. It absolutely makes sense to leverage this donation as a buildd and decommision/reallocate some of the lower-powered buildds, increasing the reliability of the buildd pool and reducing the total machine management overhead. Being the only highbank machine we have access to does imply some logistical challenges for ensuring that we continue to have good kernel support during the development cycle, so that release+1 will be supportable on the box. But this is a problem we've dealt with before, and certainly in this case the upstream kernel support is quite good, which I think makes this a fairly low risk. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature