Hi Andreas, On Mon, Mar 14, 2005 at 07:37:51AM +0100, Andreas Tille wrote: > On Sun, 13 Mar 2005, Steve Langasek wrote: > IMHO all these facts with exception of those "social" facts I marked (?) > are fullfilled by Sparc. For reference, the killer for most archs is the "98% built" criterion; from today's numbers: wanna-build stats: alpha: 97.57% up-to-date, 97.59% if also counting uploaded pkgs arm: 92.12% up-to-date, 92.15% if also counting uploaded pkgs hppa: 97.66% up-to-date, 97.68% if also counting uploaded pkgs hurd-i386: 35.59% up-to-date, 35.59% if also counting uploaded pkgs i386: 99.83% up-to-date, 99.83% if also counting uploaded pkgs ia64: 97.39% up-to-date, 97.41% if also counting uploaded pkgs m68k: 97.75% up-to-date, 97.86% if also counting uploaded pkgs mips: 96.74% up-to-date, 96.79% if also counting uploaded pkgs mipsel: 93.01% up-to-date, 93.01% if also counting uploaded pkgs powerpc: 97.99% up-to-date, 98.00% if also counting uploaded pkgs s390: 94.31% up-to-date, 94.31% if also counting uploaded pkgs sparc: 95.77% up-to-date, 95.77% if also counting uploaded pkgs [curious that ia64 is lower than some others right now -- when we looked last week, it was above 98%, so maybe etch would have a *different* 4 architectures. ;)] This may be fixable for one or more architectures for etch by getting a handle on any existing buildd problems, which I'd personally be happy to see happen, but we also have to consider that there are some bits (like ftp-master.d.o itself, as well as toolchains/kernel synchronization) that just don't scale well to the number of architectures we currently have. The 98% mark may seem a little high, but in fact it's not. Note that there's been a thread on debian-devel just this week about autobuilders holding up release-critical bugfixes, and the architectures in question are still well above 90% -- and they're not the only architectures delaying RC fixes, they're just the ones that stand out enough to flame about. Based on the experience we've had trying to keep sarge on track, setting the barrier high for etch is definitely in our best interest, IMHO. For the specific case of sparc, it's worth noting that this architecture was tied for last place (with arm) in terms of getting the ABI-changing security updates for the kernel; it took over 2 months to get all kernel-image packages updated for both 2.4 and 2.6 (which is a fairly realistic scenario, since woody also shipped with both 2.2 and 2.4), which is just way too unresponsive. The call for sparc/arm kernel folks in the last release update was intended to address this; correct me if I'm wrong, but to my knowledge, no one else has stepped forward to help the kernel team manage the sparc kernels. > >- 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. This point is *not* about supported architectures, only about architectures carried by the primary mirror network. We did consider having a single set of requirements for both "release architectures" and "primary mirror architectures", and the structure of the announcement might still reflect that, but I couldn't justify using "percent market share" as a straight criterion for release architectures. > >- 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). Well, sparc is not in any danger of being dropped from SCC. :) As I said, none of the current sarge candidate architectures are. > 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 certainly agree that portability is one of Debian's selling points, and I also have a "pet" architecture that doesn't appear to make the cut for etch; but I don't think it's a coincidence that the release cycle got longer when we doubled the arch count between potato and woody, and I *know* it's not a coincidence that we have a long release cycle for sarge while trying to wrangle those same 11 architectures. This proposal is a response to the reality that right now, the per-port cost on certain "central" teams (and hardware) in the project is high, and does not scale to handle a large number of architectures. Personally, I'd love to see our porter teams rise to the occasion and prove that we can release etch in 18 months with 8 architectures meeting these criteria instead of 4; but the first step is to shift the burden onto the porters, which is not where I believe it is today. Cheers, -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature