[please consider replacing debian-ports@ldo with the appropriate port specific list when replying.] Comrades! At our recent Essen sprint, DSA went through the release qualification matrix (for wheezy, as there isn't one for jessie, yet) and defined a set of requirements that we consider necessary for us to support a port for the next stable release. We have limited these requirements to whether DSA can support a port well or not, and we wanted to establish these requirements early in the release cycle so that our concerns can be addressed. Our requirements for machines are not new; they are: * reliability - The stable release manager requires that we operate three machines for each port: two buildd machines in different locations and one porter machine. These machines must be reliable (see mips for counterexample). * out of band management - We require the ability to manage the machines independently of their primary network interface: serial console or better, remotely-controllable power. * supportability - We require that the machines be commercialy available (within financial constraints) and that they be supportable through a warranty or post-warranty support or are otherwise easy to replace. * stability - We require that the machine's architecture have an actively-maintained stable kernel in the archive. * environment - We require that packages critical for DSA operations be available: puppet, samhain, syslog-ng, ferm/pf, etc. Historically, we have not been enforcing these requirements strictly and this has caused / continues to cause us significant operational challenges resulting in our inability to render the service levels that should reasonably be expected of us. Therefore, we believe it is important that all debian.org machines meet these requirements. Based on the list of requirements enumerated above, we currentlty are concerned about the following architectures from the perspective of using them as debian.org machines: * armel: no remote management (being worked on); no archive kernel for the machines we use. * armhf: no remote management (being worked on). * hurd: no puppet/ruby broken (for 3 months+); lack of firewall support. * mips: existing machines are either not reliable or too slow to keep up; we suspect that they may not be easily replaceable. * mipsel: the porter machine and some of the buildd machines have an implementation error for one opcode; missing kernel in the archive * sparc: no working nflog (mild concern); no stable kernels in stable (compiling clisp for instance crashes the kernel reliably on smetana). We need to run sparc with oldstable kernels to provide stable machines. That's not an option for long. * s390/x: no stable kernels; not sourceable within our budgets (currently relying on sponsors - this has not been a problem so far). We believe that it is the responsibility of the porter community to either source hardware or provide DSA with proposals regarding the hardware Debian should buy. We encourage the porter community to actively assist DSA with the resolution of the above noted concerns regarding various ports. Thanks, Martin Zobel-Helas Debian System Administration Team -- "It pays to be obvious, especially if you have a reputation for being subtle." Martin Zobel-Helas <zobel@debian.org> Debian System Administrator Debian & GNU/Linux Developer Debian Listmaster http://about.me/zobel Debian Webmaster GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B
Attachment:
signature.asc
Description: Digital signature