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

DSA concerns for jessie architectures

[please consider replacing debian-ports@ldo with the appropriate port
specific list when replying.]


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.


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

Reply to: