On 9/21/05, Andreas Barth <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
