Re: Bits (Nybbles?) from the Vancouver release team meeting
On Sun, 13 Mar 2005, Steve Langasek wrote:
- it must first be part of (or at the very least, meet the criteria for)
scc.debian.org (see below)
- the release architecture must be publicly available to buy new
- 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)
- the release architecture must have a working, tested installer
- 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
(?)
- there must be a developer-accessible debian.org machine for the
architecture.
IMHO all these facts with exception of those "social" facts I marked (?)
are fullfilled by Sparc.
- there must be a sufficient user base to justify inclusion on all
mirrors, defined as 10% of downloads over a sampled set of mirrors
Hmmm, regarding to the fact that i386 makes a real lot of percentage it
might be a quite hard limit to have 10%. I guess this reduces the number
of supported architectures by fitting to a previousely defined number
of architectures we are willing to support.
- the architecture must be freely usable (i.e., without NDAs)
- the architecture must be able to run a buildd 24/7 sustained
(without crashing)
- the architecture must have an actual, running, working buildd
- the port must include basic unix functionality, e.g resolving
DNS names and firewalling
- binary packages must be built from the unmodified Debian source
(required, among other reasons, for license compliance)
- binaries for the proposed architecture must have been built and signed
by official Debian developers
- the architecture must have successfully compiled 50% of the archive's
source (excluding architecture-specific packages)
Seems also all be true for Sparc.
- 5 developers who will use or work on the port must send in
signed requests for its addition
I'm DD and use Sparc (but do no active development to support this
hardware).
- the port must demonstrate that they have at least 50 users
Just did
wajig install popularity-contest
on my Sparc machines. The problem is that I use a *minimum* set of packages
on a server and the machines I mainly use as servers are Sparcs.
These objective requirements would be applied both to the other eight
architectures being released with sarge that are not currently regarded
as candidates for release with etch, and also to any porter requests
asking for new architectures to be added to the archive.
I do not want to start a "This is my favourite architecture - just include
ist" flamewar. It is just something I'm using and I feel the technical
parameters you mentioned (and which are very reasonable) fullfilled, while
I see reasons why SParc might show up more seldom in popularity contest for
certain reasons.
In general I would like to say that supporting a lot of architectures was
an important difference between Debian and other distributions. I know the
drawbacks of this but I just do not want to hide my opinion that I do not
like the idea of reducing the number of supported architectures that drastical.
IMHO the effect would be that people will start forking Debian for porting
issues and we will loose the power of those porters while they will spend
time for things they would not have to do else.
I think we should at least vote about such a drastic change.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: