Differences between revisions 26 and 27
Revision 26 as of 2007-01-21 10:56:57
Size: 6307
Editor: ?formorer
Comment:
Revision 27 as of 2009-03-16 03:29:58
Size: 6327
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 alpha 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 alpha 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:
   * '''HP sells [http://h18002.www1.hp.com/alphaserver/ new systems] at insane prices '''
   * '''Microway also sells [http://www.microway.com/alpha/alpha.html new alpha systems] at moderately insane price '''
   * '''HP sells [[http://h18002.www1.hp.com/alphaserver/|new systems]] at insane prices '''
   * '''Microway also sells [[http://www.microway.com/alpha/alpha.html|new alpha systems]] at moderately insane price '''
Line 13: 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.[[BR]]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.  * 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.<<BR>>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.
Line 27: Line 27:
     * '''As of 2005-10-16, there are 53 [http://popcon.debian.org popcon submissions], and 411 [http://lists.debian.org/stats/ subscribers to debian-alpha].'''
     * The [http://www.ucc.asn.au/ University Computer Club] at UWA has [http://lists.debian.org/debian-alpha/2005/10/msg00028.html some Alphas running Debian]. "We have one Alpha running Debian with a GNOME desktop for use by club members, and at least one other running Debian Sarge in the machine room. I'm not sure how many members the club currently has but there would be at least 5--10 who regularly use the Alphas." (CameronPatrick)
     * The mailserver of the [http://www.itp.uni-hannover.de/ Institute for Theoretical Physics] at the University of Hanover is running Debian GNU/Linux, currently serving 38 permanent users plus several short term users. In addition, we have got six Alpha (EV67) which are still used for numerical computations. I cannot tell the exact number of users for them, but it's between two and five. (CarstenLuckmann)
     * '''As of 2005-10-16, there are 53 [[http://popcon.debian.org|popcon submissions]], and 411 [[http://lists.debian.org/stats/|subscribers to debian-alpha]].'''
     * The [[http://www.ucc.asn.au/|University Computer Club]] at UWA has [[http://lists.debian.org/debian-alpha/2005/10/msg00028.html|some Alphas running Debian]]. "We have one Alpha running Debian with a GNOME desktop for use by club members, and at least one other running Debian Sarge in the machine room. I'm not sure how many members the club currently has but there would be at least 5--10 who regularly use the Alphas." (CameronPatrick)
     * The mailserver of the [[http://www.itp.uni-hannover.de/|Institute for Theoretical Physics]] at the University of Hanover is running Debian GNU/Linux, currently serving 38 permanent users plus several short term users. In addition, we have got six Alpha (EV67) which are still used for numerical computations. I cannot tell the exact number of users for them, but it's between two and five. (CarstenLuckmann)
Line 32: Line 32:
   * '''Debian-Installer exists for sarge. For etch see [http://lists.debian.org/debian-release/2005/10/msg00042.html].'''    * '''Debian-Installer exists for sarge. For etch see [[http://lists.debian.org/debian-release/2005/10/msg00042.html]].'''
Line 34: Line 34:
 * Porters and Upstream support: There is support by the porters and upstream. This is especially true for the toolchain and the kernel.[[BR]]This criterion doesn't forbid that Debian's and upstream's support is handled by the same persons.  * Porters and Upstream support: There is support by the porters and upstream. This is especially true for the toolchain and the kernel.<<BR>>This criterion doesn't forbid that Debian's and upstream's support is handled by the same persons.
Line 38: Line 38:
 * Archive coverage: The architecture needs to have successfully compiled the current version of the overwhelming part of the archive, excluding architecture-specific packages.[[BR]]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 coverage: The architecture needs to have successfully compiled the current version of the overwhelming part of the archive, excluding architecture-specific packages.<<BR>>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.
Line 42: Line 42:
 * 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.[[BR]]That's just what's always true. Here only for completness.  * 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.<<BR>>That's just what's always true. Here only for completness.
Line 46: Line 46:
 * 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.[[BR]]We need of course autobuilders, and they need to be able to keep up.[[BR]]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.[[BR]]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.[[BR]]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).  * 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.<<BR>>We need of course autobuilders, and they need to be able to keep up.<<BR>>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.<<BR>>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.<<BR>>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).
Line 48: Line 48:
   * '''Currently, there is only goedel.debian.org, which keeps up fine, but there is no redundancy. However, Tim Cutts (tjrc1@d.o) has offered a dual 500MHz EV67 DS20 with 2G RAM and hosting/local maintainance [http://lists.debian.org/debian-alpha/2005/10/msg00057.html].'''    * '''Currently, there is only goedel.debian.org, which keeps up fine, but there is no redundancy. However, Tim Cutts (tjrc1@d.o) has offered a dual 500MHz EV67 DS20 with 2G RAM and hosting/local maintainance [[http://lists.debian.org/debian-alpha/2005/10/msg00057.html]].'''

The goal of this page is to collect the information necessary to demonstrate that the alpha 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.

and lots of used ones are available.

  • 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 escher.debian.org, but this host is not accessible to developers for 5 months.

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

    • Developers (only add yourself)

      • Falk Hueffner (Debian Developer)

      • Thimo Neubauer (Debian Developer)

      • John Goerzen (Debian Developer)

      • Steve Langasek (Debian Developer)

      • Norbert Tretkowski (Debian Developer)

      • Peter De Schrijver (Debian Developer)

      • Tim Cutts (Debian Developer)

      • Craig Small (Debian Developer)

      • Paul Slootman (Debian Developer)

      • Alexander Wirt (Debian Developer)

    • Users

      • As of 2005-10-16, there are 53 popcon submissions, and 411 subscribers to debian-alpha.

      • The University Computer Club at UWA has some Alphas running Debian. "We have one Alpha running Debian with a GNOME desktop for use by club members, and at least one other running Debian Sarge in the machine room. I'm not sure how many members the club currently has but there would be at least 5--10 who regularly use the Alphas." (?CameronPatrick)

      • The mailserver of the Institute for Theoretical Physics at the University of Hanover is running Debian GNU/Linux, currently serving 38 permanent users plus several short term users. In addition, we have got six Alpha (EV67) which are still used for numerical computations. I cannot tell the exact number of users for them, but it's between two and five. (?CarstenLuckmann)

  • Installer: The architecture must have a working,tested installer.
  • Porters and Upstream support: There is support by the porters and upstream. This is especially true for the toolchain and the kernel.
    This criterion doesn't forbid that Debian's and upstream's support is handled by the same persons.

    • Linux, gcc, binutils, and glibc are all maintained upstream by Richard Henderson, who has write access to all four repositories, so they usually work with unmodified upstream sources. Gdb does not have a designated Alpha maintainer, but works OK at the moment.

  • Archive coverage: The architecture needs to have successfully compiled the current version of the overwhelming part of the archive, excluding architecture-specific packages.
    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.

    • the graphs on http://buildd.debian.org/stats/ show that Alpha is pretty stable shortly above 98%. The typical Alpha build failures are 64-bit issues which other architectures (ia64, amd64) have as well

  • 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.
    That's just what's always true. Here only for completness.

    • This is true.

  • 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.
    We need of course autobuilders, and they need to be able to keep up.
    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.
    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.
    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).

  • Veto powers: Security team, system administrators and release team must not veto inclusion.


CategoryEtchReleaseRecertification