Differences between revisions 1 and 2
Revision 1 as of 2005-10-09 01:37:22
Size: 5
Editor: JoeyHess
Comment:
Revision 2 as of 2005-10-09 01:45:15
Size: 4560
Editor: JoeyHess
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
... Perhaps this is only a formality, but --

The goal of this page is to collect the information necessary to demonstrate that the i386 architecture meets the [http://release.debian.org/etch_arch_criteria.html 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.<br> 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.)

Obviously the case for i386, visit Froogle or your local computer store.
Should remain true for some time before amd64 eats the whole market.

 * 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).

XXXXXXX what ones?

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

 * '''Developers (only add yourself)'''
   * '''Joey Hess (Debian Developer)'''
 * '''Users'''
  * Top of popcon.

 * Installer: The architecture must have a working,tested installer.

Probably the best supported installer of all arches, although i386 is one of the harder arches to fully support especially in newer areas like SATA.

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

Yes, i386 is the default thing supported upstream AFAIK.

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

XXXX

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

XXXX (is it really 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.<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).

Currently i386 has only one autobuilder.

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

Perhaps this is only a formality, but --

The goal of this page is to collect the information necessary to demonstrate that the i386 architecture meets the [http://release.debian.org/etch_arch_criteria.html 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.<br> 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.)

Obviously the case for i386, visit Froogle or your local computer store. Should remain true for some time before amd64 eats the whole market.

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

XXXXXXX what ones?

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

  • Developers (only add yourself)

    • Joey Hess (Debian Developer)

  • Users

    • Top of popcon.
  • Installer: The architecture must have a working,tested installer.

Probably the best supported installer of all arches, although i386 is one of the harder arches to fully support especially in newer areas like SATA.

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

Yes, i386 is the default thing supported upstream AFAIK.

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

XXXX

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

XXXX (is it really 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.<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).

Currently i386 has only one autobuilder.

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