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

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

But, I think the real question to ask and answer is not
"why do you want to drop my favourite arch?"
"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
|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
|the ftpmasters plan to bring scc.debian.org on-line and begin making
|non-release-candidate architectures available from scc.debian.org for

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

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