Differences between revisions 19 and 20
Revision 19 as of 2005-10-10 03:00:48
Size: 5356
Editor: ?GrantGrundler
Comment: Maybe not needed, but added my small "cluster" to the public list.
Revision 20 as of 2005-10-10 03:23:15
Size: 5325
Editor: MattTaggart
Comment: change to mostly match ajt's template and add machine info
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## Auto-converted by kwiki2moinmoin v2005-10-07
The goal of this page is to collect the information necessary to demonstrate that the ia64 architecture meets the [http://release.debian.org/etch_arch_criteria.html architecture recertification criteria for etch].
= Purpose =
Line 4: 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. The purpose of this page is to demonstrate that '''ia64''' meets the [http://release.debian.org/etch_arch_criteria.html architecture recertification criteria for etch].
Line 6: Line 5:
 There will be some time while an architecture goes to end-of-life where it will not be easily buyable anymore at the market, but it is still useful for Debian's users if we continue support. This criterion doesn't mean it should be directly dropped, but there will be also a time where Debian and the port's porters can't really support the architecture anymore, and it reaches its natural end-of-life. (In other words, we are stricter with adding a new architecture, than at determing whether to keep an existing architecture.) If some of these requirements are irrelevant or implausible for the port, please add a waiver request indicating why and how this isn't a problem for the arch in '''bold'''.
Line 8: Line 7:
 ''' '''[http://www.hp.com/products1/servers/integrity/index.html]*
 ''' '''[http://www.sgi.com/products/servers/]*
= Availability =
Line 11: Line 9:
 * 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). 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 13: Line 11:
'''merulo.debian.org''' There will be some time while an architecture goes to end-of-life where it will not be easily buyable anymore at the market, but it is still useful for Debian's users if we continue support. This criterion doesn't mean it should be directly dropped, but there will be also a time where Debian and the port's porters can't really support the architecture anymore, and it reaches its natural end-of-life. (In other words, we are stricter with adding a new architecture, than at determing whether to keep an existing architecture.)
Line 15: Line 13:
 * 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.  1. [http://www.hp.com/products1/servers/integrity/index.html]*
 2. [http://www.sgi.com/products/servers/]*
Line 17: Line 16:
 We are counting users for the second criteria, not machines; e.g., one s390-installation with 50,000 users fullfils the user criterion just fine. = Developer machines =
Line 19: Line 18:
 * '''Developers (only add yourself)'''
   * '''dann frazier (Debian Developer)'''
   * '''lamont jones (Debian Developer)'''
   * '''al stone (Debian Developer)'''
   * '''Khalid Aziz (Debian Developer)'''
   * '''Kyle McMartin (Debian Developer)'''
 * '''Users'''
   ''' '''[http://popcon.debian.org popcon data] is currently lacking; please apt-get install popularity-contest*
   * '''We have a single ia64 machine in our lab at HP with well over 50 users. --dannf'''
   * '''We have around 10 machines shared with around 30 developers -- ianw'''
   * '''We have 10 machines shared between ~50 users (actually: There are 3129 student accounts which have access to those machines, but they are seldom uses -- Tolimar'''
   * '''I have three public ZX1 systems with ~50 accounts and ~6 upstream developers as regular users. See http://www.parisc-linux.org/cluster.html and look under Cupertino Test Ring. -- ggg'''
   * '''PING, the computer club at the University of Oslo, has an IA64 as its primary login server, with 86 accounts of whom ~20 use it regularly. -- ilmari'''
The architecture must have a developer-available (i.e. debian.org) machine that contains the usual development chroots (at least stable, testing, unstable).
Line 33: Line 20:
 * Installer: The architecture must have a working, tested installer.  1. '''merulo.debian.org''' - maintained by DSA (Matt Taggart and dann frazier local admins), connectivity via HP, porting machine.
 2. '''merkel.debian.org''' - maintained by DSA (Matt Taggart and dann frazier local admins), connectivity via HP, general use machine (no chroots).

= Port maintainers =

The Debian port is maintained by the following developers, who are familiar with arch-specific
issues for this port

 1. dann frazier
 2. lamont jones
 3. al stone
 4. Khalid Aziz
 5. Kyle McMartin

= 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.

We are counting users for the second criteria, not machines; e.g., one s390-installation with 50,000 users fullfils the user criterion just fine.

''' '''[http://popcon.debian.org popcon data] is currently lacking; please apt-get install popularity-contest*

 1. We have a single ia64 machine in our lab at HP with well over 50 users. --dannf'''
 2. We have around 10 machines shared with around 30 developers -- ianw'''
 3. We have 10 machines shared between ~50 users (actually: There are 3129 student accounts which have access to those machines, but they are seldom uses -- Tolimar'''
 4. PING, the computer club at the University of Oslo, has an IA64 as its primary login server, with 86 accounts of whom ~20 use it regularly. -- ilmari'''

= Installer =
The architecture must have a working, tested installer.
Line 36: Line 52:
 * Porters and Upstream support: There is support by the porters and upstream. This is especially true for the toolchain and the kernel. = Upstream support =
There is support by the porters and upstream. This is especially true for the toolchain and the kernel.
Line 38: Line 55:
Upstream support is provided by:

 * glibc: ...
 * gcc: ...
 * g++: ...
 * kernel: ...
 * boot loader: ...
 * ...
Line 40: Line 65:
 * Archive coverage: The architecture needs to have successfully compiled the current version of the overwhelming part of the archive, excluding architecture-specific packages. = Archive coverage and Autobuilder support =

The architecture needs to have successfully compiled the current version of the overwhelming part of the archive, excluding architecture-specific packages.

 * The port is currently at 98% up to date according to [http://buildd.debian.org/stats/graph2-week.png the buildd stats] (95% cut off)
 * The port has currently built 96% of the archive according to [http://buildd.debian.org/stats/graph-week.png the buildd stats] (90% cut off)
Line 44: Line 74:
 * 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. = Archive cleanliness =
Line 46: Line 76:
 That's just what's always true. Here only for completness. 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.
Line 48: Line 78:
The port builds from unmodified Debian source.
Line 49: Line 80:
 * 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. = Autobuilders =
Line 51: Line 82:
 We need of course autobuilders, and they need to be able to keep up. 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.
Line 53: Line 84:
 As mentioned multiple times, there is a nontrivial cost to each buildd, which increases super-linearly; there have been cases in the past where this resulted in ports with many autobuilders slacking when updates were necessary. The following machines run buildds for the port:
 1. caballero.debian.org - connectivity via Black Cat Networks, buildd logs checked by LaMont Jones, admined by DSA (Jonathan McDowell is local admin)
Line 55: Line 87:
 Redundancy is necessary just in case some buildd has hardware failures or whatever else. History told the release team that redundancy is really necessary. Noone in the release team wants again to track where a box in europe is just located, and prod some developer in that country to pick the box up, because that's largest blocker of the next stable release. = Vetoes =
Line 57: Line 89:
 Of course, autobuilders can have hardware maintainence. But the autobuilers need to be able to run 24x7, and the need to be generally up all the time (and thanks to the redundancy above, there should always be an autobuilder currently running). The security team have noted the following problems in supporting the architecture:
Line 59: Line 91:
 * '''caballero.debian.org'''  * None
Line 61: Line 93:
 * Veto powers: Security team, system administrators and release team must not veto inclusion. The Debian admin team have noted the following problems in supporting the architecture:

 * None

The release team have noted the following problems in supporting the architecture:

 * None

Purpose

The purpose of this page is to demonstrate that ia64 meets the [http://release.debian.org/etch_arch_criteria.html architecture recertification criteria for etch].

If some of these requirements are irrelevant or implausible for the port, please add a waiver request indicating why and how this isn't a problem for the arch in bold.

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.

There will be some time while an architecture goes to end-of-life where it will not be easily buyable anymore at the market, but it is still useful for Debian's users if we continue support. This criterion doesn't mean it should be directly dropped, but there will be also a time where Debian and the port's porters can't really support the architecture anymore, and it reaches its natural end-of-life. (In other words, we are stricter with adding a new architecture, than at determing whether to keep an existing architecture.)

  1. [http://www.hp.com/products1/servers/integrity/index.html]*

  2. [http://www.sgi.com/products/servers/]*

Developer machines

The architecture must have a developer-available (i.e. debian.org) machine that contains the usual development chroots (at least stable, testing, unstable).

  1. merulo.debian.org - maintained by DSA (Matt Taggart and dann frazier local admins), connectivity via HP, porting machine.

  2. merkel.debian.org - maintained by DSA (Matt Taggart and dann frazier local admins), connectivity via HP, general use machine (no chroots).

Port maintainers

The Debian port is maintained by the following developers, who are familiar with arch-specific issues for this port

  1. dann frazier
  2. lamont jones
  3. al stone
  4. Khalid Aziz
  5. Kyle ?McMartin

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.

We are counting users for the second criteria, not machines; e.g., one s390-installation with 50,000 users fullfils the user criterion just fine.

[http://popcon.debian.org popcon data] is currently lacking; please apt-get install popularity-contest*

  1. We have a single ia64 machine in our lab at HP with well over 50 users. --dannf

  2. We have around 10 machines shared with around 30 developers -- ianw

  3. We have 10 machines shared between ~50 users (actually: There are 3129 student accounts which have access to those machines, but they are seldom uses -- Tolimar

  4. PING, the computer club at the University of Oslo, has an IA64 as its primary login server, with 86 accounts of whom ~20 use it regularly. -- ilmari

Installer

The architecture must have a working, tested installer.

The sarge installer works well; the daily builds are currently broken due to #326103

Upstream support

There is support by the porters and upstream. This is especially true for the toolchain and the kernel.

Upstream support is provided by:

  • glibc: ...
  • gcc: ...
  • g++: ...
  • kernel: ...
  • boot loader: ...
  • ... This criterion doesn't forbid that Debian's and upstream's support is handled by the same persons.

Archive coverage and Autobuilder support

The architecture needs to have successfully compiled the current version of the overwhelming part of the archive, excluding architecture-specific packages.

  • The port is currently at 98% up to date according to [http://buildd.debian.org/stats/graph2-week.png the buildd stats] (95% cut off)

  • The port has currently built 96% of the archive according to [http://buildd.debian.org/stats/graph-week.png the buildd stats] (90% cut off) Our back-of-the-envelope number is 98% of the archive. We don't have a good way to measure an architecture's compliance with this yet, but we'll work on figuring that out; of course we will exclude hardware-specific packages and buggy packages with severe portability issues in optional/extra packages, but porters must take responsibility for working with maintainers to fix portability issues.

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.

The port builds from unmodified Debian source.

Autobuilders

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.

The following machines run buildds for the port:

  1. caballero.debian.org - connectivity via Black Cat Networks, buildd logs checked by LaMont Jones, admined by DSA (Jonathan ?McDowell is local admin)

Vetoes

The security team have noted the following problems in supporting the architecture:

  • None

The Debian admin team have noted the following problems in supporting the architecture:

  • None

The release team have noted the following problems in supporting the architecture:

  • None