Differences between revisions 3 and 14 (spanning 11 versions)
Revision 3 as of 2005-09-23 02:46:11
Size: 2513
Editor: AnthonyTowns
Comment:
Revision 14 as of 2005-10-12 07:25:22
Size: 3096
Editor: ?PetrSalinger
Comment: add links for rest of architectures
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from IRC/debian-tech/Event/20051002
Line 7: Line 8:
2005/10/02 00:00-01:00 UTC 2005/10/09 00:00-02:00 UTC
Line 19: Line 20:
DannFrazier has started qualification pages for [http://wiki.debian.net/?ia64EtchReleaseRecertification ia64] and [http://wiki.debian.net/?hppaEtchReleaseRecertification hppa]. 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]...

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/09 00:00-02:00 UTC

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

Hosts

?SteveLangasek (vorlon) and AnthonyTowns (aj)

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

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

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.