Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

[Dirk Eddelbuettel <edd@debian.org>]

Matthew Palmer <mpalmer <at> debian.org> writes:
> On Tue, Feb 22, 2005 at 03:15:58AM +0000, Dirk Eddelbuettel wrote:
> > undisputed:  essentially all users are on i386 clearly dominating all other 
> > arches, with a fraction of users in maybe two, three, four other arches --- 
> > and comparitively nobody in the other fringe arches we keep around for no 
> > good reason. And I still believe it delays our releases.  As you say, there 
> 
> You can believe in the tooth fairy, too, but it doesn't make it true.  Since
> you're trying to convince others to join your tooth fairy worshipping
> religion, it might be useful to provide some evidence to back your belief.

Sorry, you just scored against your own team.  

I was quoting a post with actual download numbers that actually demonstrate 
that the vast majority of users are on i386: see http://blog.bofh.it/id_66.

For your convenience, I quote the numbers here again along with a quick
percentage calculation:

> md <- read.table("/tmp/md.txt", header=TRUE, row.names=1)
> md <- cbind(md, percent=round(100*md[,1]/md["total",1], 4))
> md
        files.downloaded  percent
i386             1285422  70.5079
all               504789  27.6886
powerpc            17754   0.9738
ia64               10111   0.5546
sparc               3336   0.1830
arm                  850   0.0466
alpha                507   0.0278
hppa                 204   0.0112
mipsel                91   0.0050
m68k                  15   0.0008
mips                   7   0.0004
s390                   4   0.0002
total            1823090 100.0000
 

> I believe we haven't seen any evidence that all our architectures has
> delayed any release.  DI was a potential sticking point, but it's already
> sorted due to the hard work by the relevant porters while we're still
> waiting for other technical issues to work themselves out.

It delays our releases in the sense that it affects our resources:
- available maintainer and developer time,
- cpu cycles (witness Wouter's request to compile big packages rarely),
- network bandwith (witness the discussion on mirror efficiency),
- mirrror capacity (witness the sad state of amd64),
- security response time (more builds to do)
and that it 
- increases the load on infrastructure (t-p-u, security)
- scarce resource such as release managers, ftp admins, ...
if we have to look after arches that are *not really used*.

As you say so cogently: "it might be useful to provide some evidence to back 
your belief".  

Consider the ball in your court, and please prove with tangible numbers
how the approximate benefit from the minor arches is "roughly" equivalent
to that of arches being used.  Hand-waving ("find more bugs") won't do.

Dirk