Let's analyze the requirements the release team sent for release architectures:
- it must first be part of (or at the very least, meet the criteria for) scc.debian.org (see below) - there must be a developer-accessible debian.org machine for the architecture. That's obvious. - the release architecture must have a working, tested installer Assuming sarge releases with all 11 woody architectures, and the sarge installer will be used for etch, too, this shouldn't be a problem for any of these architectures. - the Security Team must be willing to provide long-term support for the architecture - the Debian System Administrators (DSA) must be willing to support debian.org machine(s) of that architecture - the Release Team can veto the architecture's inclusion if they have overwhelming concerns regarding the architecture's impact on the release quality or the release cycle length Assuming this is not being abused that's obvious. - the release architecture must be publicly available to buy new That's currently easily met by all 11 woody architectures. Alpha and hppa will obviously be the first candidates being affected by this rule, but I fail to see how dropping these two architectures will have a great impact on the release cycle. - the release architecture must have N+1 buildds where N is the number required to keep up with the volume of uploaded packages - the value of N above must not be > 2 - the release architecture must have successfully compiled 98% of the archive's source (excluding architecture-specific packages) These are restrictions only imposed by testing. If testing imposes restrictions with the effect of removing at about two thirds of the architectures from Debian stable, shouldn't it be time to evaluate whether the price of testing is really worth it? If Debian would dump testing [1], they would automatically go away. - issues with space on ftp.debian.org and on mirrors (especially hindering amd64) It might be a better point to start moving non-released architectures (GNU Hurd and sh) to a different location. Depending on what exactly hinders amd64 today, this might be sufficient [2]. Regarding mirrors, offering only m architectures or offering only Debian stable for n architectures should be solvable on a per-mirror basis without any effect on the release management. cu Adrian [1] http://lists.debian.org/debian-devel/2005/03/msg01320.html [2] my impression is that communication problems between the amd64 porters and the ftp admins might be a bigger problem for including the amd64 port than technical problems -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]