delay meeting due to unavailability
← Revision 16 as of 2009-03-16 03:33:40
converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 8:||Line 8:|
|2005/10/02 00:00-01:00 UTC||2005/10/09 00:00-02:00 UTC|
|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:|
|DannFrazier has started qualification pages for [http://wiki.debian.net/?ia64EtchReleaseRecertification ia64] and [http://wiki.debian.net/?hppaEtchReleaseRecertification hppa].||Here's a [[EtchReleaseRecertificationTemplate|blank qualification page]].
There are qualification pages for
[[mipsEtchReleaseRecertification|mips and mipsel]],
Here's a [[EtchReleaseRecertificationSummary|summary page]]...
There is a [[IRC/debian-tech/Logs/20051009-releasequalification|log]] of the session available
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)
Here's a ?blank qualification page.
Here's a summary page...
There is a log of the session available
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.