about Nybbles : how to keep all those archs releasable complying with the Vancouver Project
| * To: debian-devel-announce@lists.debian.org
| * Subject: Bits (Nybbles?) from the Vancouver release team meeting
| * From: Steve Langasek <vorlon@debian.org>
| * Date: Sun, 13 Mar 2005 20:45:09 -0800
We all have seen this proposal for "dropping architecture" and a lot
of us are crying because their favourite pet architecture will be
dropped.
But, I think the real question to ask and answer is not
"why do you want to drop my favourite arch?"
but
"what must be done in order to my favourite arch not to be dropped?".
Let us see what is exactly the proposal.
|The release team and
|the ftpmasters are mutually agreed that it is not sustainable to
|continue making coordinated releases for as many architectures as sarge
|currently contains, let alone for as many new proposed architectures as
|are waiting in the wings.
|Therefore, we're planning on not releasing most of the minor
|architectures
|starting with etch. They will be released with sarge, with all that
|implies (including security support until sarge is archived), but they
|would no longer be included in testing.
Ok, they say they want to drop your $arch because they are fed-up with
it, it slow the release, et caetera
|This is a very large step, and while we've discussed it fairly
|thoroughly and think we've got most of the bugs worked out, we'd
|appreciate hearing any comments you might have.
But now we wille see the *real* guidelines to choose which release
|This change has superseded the previous SCC (second-class citizen
|architecture) plan that had already been proposed to reduce the amount
|of data Debian mirrors are required to carry; prior to the release of
|sarge,
|the ftpmasters plan to bring scc.debian.org on-line and begin making
|non-release-candidate architectures available from scc.debian.org for
|unstable.
it exist a plan in order to define second class citizen archs (scc)
not distributed by main debian ftp but accessible from some
scc.debian.org ftp.
|Note that this plan makes no changes to the set of supported release
|with the result that [the post-release] testing will
|contain a greatly reduced set of architectures, according to the
|following objective criteria:
there is four sort of arch I number those groups 1a 1b 2 and 3
I will begin with number 3 :
in number 3 group, there are archs not supported at all by the Debian
project.
Debian don't *know* about those archs.
In order to go into the second group, archs must comply with those
requirements :
|- the architecture must be freely usable (i.e., without NDAs)
It seems to me reasonable thing, we don't support platform
we cannot release software developed on.
|
|- the architecture must be able to run a buildd 24/7 sustained
| (without crashing)
|
|- the architecture must have an actual, running, working buildd
reasonable too, we must be able to build the binary package for.
|
|- the port must include basic unix functionality, e.g resolving
| DNS names and firewalling
technical reason, we must access the buildd on Internet
|
|- binary packages must be built from the unmodified Debian source
| (required, among other reasons, for license compliance)
no more to say
|- binaries for the proposed architecture must have been built and signed
| by official Debian developers
seems ok to me
|
|- the architecture must have successfully compiled 50% of the archive's
| source (excluding architecture-specific packages)
normal, an architecture which don't compile debian packages cannot
pretend to be included with debian.
|
|- 5 developers who will use or work on the port must send in
| signed requests for its addition
we must have developers for this arch
|
|- the port must demonstrate that they have at least 50 users
if there is no users there is no point to work on a distribution
the architectures which pass those 9 points are now in the group 2 (scc)
i.e. debian distribute some compiled software for it but there is no
official testing and stable-security support.
I think, it do not prohibit the porters to implement to some stage these
feature and to use the debian infrastructure to do it, just as (I think)
non-free do.
Next, in order to be fully supported by Debian (the group number 1),
archs must comply with some more requirements :
|- the release architecture must be publicly available to buy new
it's the point which is the most problematic to me, if I understand
why we can't support non-existant archs, I think that even old but
largely deployed archs should go to stage 1.
|- the release architecture must have N+1 buildds where N is the number
| required to keep up with the volume of uploaded packages
If we want to have a real-life testing and stable-security build working
this is a requirement. We can't distribute security-update if we
can't build it, the "+1" is the minimum redundancy.
|- the value of N above must not be > 2
I don't understand this statement. Does this mean that "N don't *have*
to be >2" or that "N must be <2" (my english is too poor)
|- the release architecture must have successfully compiled 98% of the
| archive's source (excluding architecture-specific packages)
If the release is a Debian release, the release must have the Debian
package. The "architecture-specific" statement let a place for
interpretation when it's needed.
|- the release architecture must have a working, tested installer
Just ok.
|
|- the Security Team must be willing to provide long-term support for
| the architecture
Yes, stable *is* security and without Security Team support there is no
security.
But : the security team must welcome members from all archs and, if they
don't want to work with some arch (or with some devloper if he's the
only one suitable for $arch-security support) not yet supported by the
Team they must explain why.
|- the Debian System Administrators (DSA) must be willing to support
| debian.org machine(s) of that architecture
|
|- there must be a developer-accessible debian.org machine for the
| architecture.
Yes, and the same apply for DSysAdmin group as for Security Team
|
|- 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
The Release Team can have some good reason to veto the inclusion, but
this veto is never definitive and the reasons must be publicly explained.
synthesis :
archs in group number 1 (fully supported) must have :
a reliable build system (the N+1 buildd)
all the package which compose Debian
a Security Team maintaining it
some machine must be DD accessible
that is the *fully-supported* Debian.
This group is splitted in two parts :
1b : *fully-supported* and distributed by Debian
1a : *fully-supported* and distributed by the main Debian mirrors
the criterion for 1a group is 10% of downloads i.e. the most downloaded
architecture, the 1b archs have a reduced set of mirrors but are
supported as well as the 1a group.
And so now what must I do in order to have my favourite arch
included in next release :
- I must have a reliable build system.
The actual one don't fit ? why ?
because my arch is too slow ? I will try to improve distcc or
some cross-compiling tool
because the actual build sytem sucks ? I will help to create a new
one, e.g. involving or supporting the multibuild project.
- I must have some testing support
The actual don't fit ? I will help to create new scripts.
I will ask for a real communication about what is needed in this
field.
- I must have some security support
I will involve in Security teams.
I will maintain my ports/packages in order to help security team
I will be aware about the internals of Security Team
I think, that quite all the eleven archs released with Sarge can
comply the steps in order to be releasable with etch.
I think too that arch which can't comply this basic rules don't have
place in Debian, even if Debian can help it and provide a real
infrastructure for it.
A Debian fanatic, who could became a future Debian Developer if he can.
Reply to: