Re: architecture-specific release criteria - requalification needed
On 9/21/05, Andreas Barth <aba@not.so.argh.org> wrote:
> These criteria do _not_ control addition of an architecture to unstable,
> but rather apply to architectures which the ftp-masters have accepted
> into unstable and are targetting testing and the next stable release.
> In other words, an architecture that fails these criteria can still be
> part of unstable.
Andreas,
Can you outline the requirements for a new architecture (e.g.
debian-armeb[1]) to be added to unstable ? Or at least be added to the
existing buildd infrastructure?
Below are representative responses to the requalification criteria for
the debian-armeb port, and the debian-armeb porting team is very
interested in understandig how to move forward to be added to the buildd
infrastructure and eventually be able to contribute to Debian unstable.
> | * Availability:
> | The architecture needs to be available for everybody, i.e.
The Linksys NSLU2 is available for USD$80 at various online retail
outlets. Other consumer-level armeb machines suitable for running
Debian can be readily purchased for less than USD$200. Other high-end
armeb machines can range into the tens of thousands of dollars ...
> | * Developer availability: The architecture must have a
> | developer-available (i.e. debian.org) machine that contains the
> | usual development chroots (at least stable, testing, unstable).
We can easily afford (from user contributions of money) to donate two or
three machines for Debian developers to use.
> | * Users: The architecture needs to prove that developers and users
> | are actually using it. Five Developers needs to certify in that
> | they're actively developing on this architecture, and it needs to
> | be demonstrated that at least 50 users are using the platform.
We have no DDs on the team at the moment, but we do have a number of
DDs interested, and expect to be able to meet the requalification
requirement of 5 DDs actively developing after some period of time
(either by recruiting existing DDs, and/or by the DD applications of the
core armeb porting team progressing to approval). We are tracking
installations now[2] and are half-way to the goal of 50 in less than two
months of operation. We also intend using the popularity-contest to
assist in tracking progress towards meeting this requirement.
However, how does one get "armeb" recognised as a valid option for the
graphs on http://popcon.debian.org? Will simply sending in valid survey
results with armeb as the architecture cause the graphs on that page to
list armeb separately?
> | * Installer: The architecture must have a working, tested installer.
We have a fairly easy method of bootstrapping Debian on an NSLU2 right
now[3], and have people working on porting the standard debian-installer
(we need one that works across the network out of the box, since the
NSLU2 does not have a console without modifying the hardware[4]).
> | * Porters and Upstream support: There is support by the porters and
> | upstream. This is especially true for the toolchain and the
> | kernel.
There is a very active team supporting Linux on the NSLU2, and other
armeb devices[5]. We are running the 2.6.12 kernel at the moment.
> | * Archive coverage: The architecture needs to have successfully
> | compiled the current version of the overwhelming part of the
> | archive, excluding architecture-specific packages.
We currently have 2500+ stable packages released[6] (including all of
important, required and standard), and we have started building the same
set (important, required and standard) for unstable as well.
This is where the chicken-and-egg situation comes into play.
We *really* need to be hooked into the buildd system to be able to
automatically build the rest of the stable, testing and unstable
releases. This is our top-most priority, and we hope to get help on
this point from the Debian infrastructure teams. We have buildd clients
ready and running, but we need a server to feed them build requests.
> | * Archive cleanliness: All binary packages need to be built from
> | unmodified sources (i.e. from the source found in the
> | ftp archive), and all binary packages need to be built by Debian
> | developers.
None of the current team building the armeb packages are DDs, but we
have at least two DDs who may be willing to sponsor the port. The
question is whether we can get some armeb boxes into the buildd
infrastructure now, and therefore have packages built automatically, or
whether we have to rebuild all our packages after one of our team
becomes a DD (or a DD takes on the task of building the packages for
us).
We are keeping patches[7] for the armeb port separate, and are ready to
contribute them now, or at any future time that is more appropriate.
Another chicken-and-egg - are package maintainers expected to accept
patches for architectures that are not yet official?
> | * Autobuilder support:
> | The architecture is able to keep up with unstable
> | with not more than two buildds,
There are high-end armeb machines which would probably be able to do
this. We would much prefer to meet the same goal with a larger number
of less expensive machines.
> | has redundancy in the autobuilder network,
Using less expensive machines enables this.
> | keeps their autobuilders running for 24x7,
> | has autobuilders acceptable for security support.
Chicken-and-egg again. We need automatic support for keeping the
autobuilders busy. The machines we currently use run 24x7, but the
feeding of items to build and the determination of build dependencies is
currently done manually (which is very tedious). We really need to be
hooked into the buildd infrastructure.
> | * Veto powers: Security team, system administrators and release team
> | must not veto inclusion.
We are at the mercy of those teams for this requirement.
In summary, we are looking for guidance in how to take the right steps
towards approval of armeb as a new Debian architecture.
-- Signed, the debian-armeb porting team.
[1]: http://lists.debian.org/debian-devel/2005/09/msg00860.html
[2]: http://www.debonaras.org/wiki/Info/OpenDebianSlugUsers
[3]: http://www.nslu2-linux.org/wiki/DebianSlug/OpenDebianSlug
[4]: http://www.nslu2-linux.org/wiki/HowTo/AddASerialPort
[5]: http://www.nslu2-linux.org
[6]: http://ftp.debonaras.org/debian
[7]: http://ftp.debonaras.org/patches
Reply to: