An alternative analysis of the etch architecture proposal
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
Reply to: