Differences between revisions 15 and 16
Revision 15 as of 2005-10-16 12:46:33
Size: 3197
Editor: ?SteveLangasek
Comment: link the log
Revision 16 as of 2009-03-16 03:33:40
Size: 3161
Editor: anonymous
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 18: Line 18:
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]. 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]].
Line 20: Line 20:
Here's a [wiki:EtchReleaseRecertificationTemplate blank qualification page]. Here's a [[EtchReleaseRecertificationTemplate|blank qualification page]].
Line 23: Line 23:
[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].
[[alphaEtchReleaseRecertification|alpha]],
[[amd64EtchReleaseRecertification|amd64]],
[[armEtchReleaseRecertification|arm]],
[[hppaEtchReleaseRecertification|hppa]],
[[i386EtchReleaseRecertification|i386]],
[[ia64EtchReleaseRecertification|ia64]],
[[m68kEtchReleaseRecertification|m68k]],
[[mipsEtchReleaseRecertification|mips and mipsel]],
[[powerpcEtchReleaseRecertification|powerpc]],
[[s390EtchReleaseRecertification|s390]] and
[[sparcEtchReleaseRecertification|sparc]].
Line 35: Line 35:
Here's a [wiki:EtchReleaseRecertificationSummary summary page]... Here's a [[EtchReleaseRecertificationSummary|summary page]]...
Line 37: Line 37:
There is a [wiki:IRC/debian-tech/Logs/20051009-releasequalification log] of the session available There is a [[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.

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 the mail to -devel-announce, and the release team's criteria page and status page.

Here's a ?blank qualification page.

There are qualification pages for alpha, amd64, arm, hppa, i386, ia64, m68k, mips and mipsel, powerpc, s390 and sparc.

Here's a summary page...

There is a 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.