Differences between revisions 23 and 24
Revision 23 as of 2006-06-21 11:45:55
Size: 2990
Editor: BastianBlank
Comment:
Revision 24 as of 2009-03-16 03:34:08
Size: 2994
Editor: anonymous
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
The goal of this page is to collect the information necessary to demonstrate that the s390 architecture meets the [http://release.debian.org/etch_arch_criteria.html architecture recertification criteria for etch]. The goal of this page is to collect the information necessary to demonstrate that the s390 architecture meets the [[http://release.debian.org/etch_arch_criteria.html|architecture recertification criteria for etch]].
Line 3: Line 3:
 * Availability: The architecture needs to be available for everybody, i.e. it must be available without ["NDAs"] and it must be possible to buy machines on the market.  * Availability: The architecture needs to be available for everybody, i.e. it must be available without [[NDAs]] and it must be possible to buy machines on the market.
Line 5: Line 5:
   * zSeries is actively developed by IBM. They announced a new machine [http://www-03.ibm.com/servers/eserver/zseries/z9109 z9] some weeks ago.    * zSeries is actively developed by IBM. They announced a new machine [[http://www-03.ibm.com/servers/eserver/zseries/z9109|z9]] some weeks ago.

The goal of this page is to collect the information necessary to demonstrate that the s390 architecture meets the architecture recertification criteria for etch.

  • Availability: The architecture needs to be available for everybody, i.e. it must be available without ?NDAs and it must be possible to buy machines on the market.

    • zSeries is actively developed by IBM. They announced a new machine z9 some weeks ago.

  • Developers availability: The architecture must have a developer-available (i.e. debian.org) machine that contains the usual development chroots (at least stable, testing, unstable).
    • There is raptor.debian.org.
  • Users: The architecture needs to prove that developers and users are actually using it. Five Developers need to certify in that they're activly developing on this architecture, and it needs to be demonstrated that at least 50 users are using the platform.
    • Developers
      • Bastian Blank (Debian Developer)
      • Frank Kirschner (Debian Developer)
      • Frans Pop (Debian Developer - Installer stuff only)
      • Kilian Krause (Debian Developer)
      • Matthias Klose (Debian Developer - GCC, Python testing)
      • Frederik Schüler (Debian Developer)
    • Users
      • ZIVIT (Zentrum fuer Informationsverarbeitung und Informationstechnik), 1500 Users
      • Stephen Frazier - State of Oklahoma Department of Corrections
      • Jochen Hein - Preparation of training material for Linux on zSeries trainings
  • Installer: The architecture must have a working, tested installer.
    • S/390 is supported by Debian-Installer. Support for 2.6 is currently in unstable.
  • Porters and Upstream support: There is support by the porters and upstream. This is especially true for the toolchain and the kernel.
    • GCC, Linux, glibc, bintuils and gdb support is developed by IBM and integrated upstream.
  • Archive coverage: The architecture needs to have successfully compiled the current version of the overwhelming part of the archive, excluding architecture-specific packages.
  • Archive cleanliness: All binary packages need to be built from unmodified sources (i.e. from the source found in the ftp archive), and all binary packages need to be built by debian developers.
  • Autobuilder support: The architecture is able to keep up with unstable with not more than two buildds, has redundancy in the autobuilder network, keeps their autobuilders running for 24x7, has autobuilders acceptable for security support.
    • There are two autobuilder available, debian01.zseries.org and debian-31.osdl.marist.edu, one of them can easily keep up with unstable. Currently one builds oldstable, stable, stable-security and testing, both do unstable.
  • Veto powers: Security team, system administrators and release team must not veto inclusion.


CategoryEtchReleaseRecertification