Differences between revisions 14 and 15
Revision 14 as of 2005-10-12 07:25:22
Size: 3096
Editor: ?PetrSalinger
Comment: add links for rest of architectures
Revision 15 as of 2005-10-16 12:46:33
Size: 3197
Editor: ?SteveLangasek
Comment: link the log
Deletions are marked like this. Additions are marked like this.
Line 37: Line 37:
There is a [wiki:IRC/debian-tech/Logs/20051009-releasequalification log] of the session available

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.


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

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


?SteveLangasek (vorlon) and AnthonyTowns (aj)


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

Here's a [wiki:?EtchReleaseRecertificationTemplate blank qualification page].

There are qualification pages for [wiki:alphaEtchReleaseRecertification alpha], [wiki:amd64EtchReleaseRecertification amd64], [wiki:armEtchReleaseRecertification arm], [wiki:hppaEtchReleaseRecertification hppa], [wiki:i386EtchReleaseRecertification i386], [wiki:ia64EtchReleaseRecertification ia64], [wiki:m68kEtchReleaseRecertification m68k], [wiki:mipsEtchReleaseRecertification mips and mipsel], [wiki:powerpcEtchReleaseRecertification powerpc], [wiki:s390EtchReleaseRecertification s390] and [wiki:sparcEtchReleaseRecertification sparc].

Here's a [wiki:EtchReleaseRecertificationSummary summary page]...

There is a [wiki:IRC/debian-tech/Logs/20051009-releasequalification log] of the session available

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.