Steve Langasek <[EMAIL PROTECTED]> writes:
> 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. ;)]
Please remove all contib/non-free packages, remove packages in p-a-s
that were previously build and remain in the w-b db, and then use the
total of main packages not excluded by p-a-s as total for the % count.
Unless you do that those numbers are just wrong and misleading. Both
the compiled and the up-to-date graphs on buildd.d.o suffer from this
miscounting.
> 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.
Which is purely a problem of starvation in the needs-build
queue. Something that would be a few days delay with a fifo turns into
a month without any build attempt.
Anyway, this goes towards the "2 buildds must be able to keep up with
etch" criteria for excluding archs.
> 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.
That is a realy good argument for excluding an arch. Much better than
pulling some magic 98% or 2 buildds out of a hat and hope that keeps
them out.
>> >- 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.
Release should be governed by the amount of developers, if the can
keep up, if the buildd works and so on. *Quality*
Mirroring should be governed by the amount of users (as in downloads),
the amount of traffic for an arch. No point having more mirrors than
users. *Quantity*
There might be 100 firms downloading to their proxy and maintaining 1
million s390 systems (VMs) with 10 million users. Does s390 then get
kicked out of the release because they download efficiently, only 100
downloads instead of 10 million?
While the amount of developers, users and downloads tends to correlate
roughly it has been said in the past that especialy s390 has a
different dispersal pattern by nature of its hardware.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
