Release Qualification

The aim of this event is to come up with a "qualification declaration" for as many architectures as possible (particularly i386!), and to come up with ideas on how to better refine the qualification requirements.

Time

2005/10/02 00:00-01:00 UTC

(Saturday afternoon in America, Saturday night in western Europe, Sunday morning in Asia/Australia)

References

See [http://lists.debian.org/debian-devel-announce/2005/09/msg00012.html the mail to -devel-announce], and the release team's [http://release.debian.org/etch_arch_criteria.html criteria page] and [http://release.debian.org/etch_arch_qualify.html status page].

More thoughts

We probably need to create some wiki pages to gather signatures from developers and users in support of each arch. Do we expect "developers" who support an arch to actively ensure it's maintained, or just to have a powerpc laptop, or an old sparc that they want to run Debian on? Probably the former. How about users? Maybe we should try for a "what do you (or your users) use the machines for?" response, so the release team can judge if it's "real" use or just a "toy", whatever that means.

What's "upstream"? gcc? kernel? glibc? Does hardware manufacturer support count? Is it worth noting whether the support is paid (and thus likely more dedicated) or hobbiest (perhaps less likely to completely disappear if the market shifts)?

How do we measure "keeping up with unstable"? Maybe some sort of "number of packages each buildd can rebuild in a week" metric is more stable, and can be compared with "average number of packages uploaded in a week" to work out if the port can keep up with unstable reasonably. Probably worth noting contact details for the buildds too (machine info, local admin, who's looking at the logs).

hurd-i386 and amd64 are missing -- so probably should have criteria for "arch in unstable", and "basic unix functionality".

Is it worth extending this to look at architectures who want to get into the archive? Things like ppc64 probably warrant some sort of explanation of "why should this be a separate architecture, rather than a separate kernel for an existing architecture", likewise s390 variants and the various mips and sh variants.