[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

An alternative analysis of the etch architecture proposal

Let's analyze the requirements the release team sent for release 

- 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

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.


[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: