[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 zo...@debian.orgDebian 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
signature.asc
Description: Digital signature