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>]

Brian Nelson <pyro <at> debian.org> writes:
> On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote:
> > On Sun, Feb 20, 2005 at 10:57:47PM +0000, Dirk Eddelbuettel wrote:
> > > But a total of eleven is insane.
> > 
> > It is sometimes hard to get them all to work, yes.
> > 
> > It also vastly increases the quality of the Free Software in our
> > archive, as we discover bugs that appear only on one architecture.
> 
> That's an overstatement.  Simply having two architectures (i386 and ppc)
> would be enough to reveal nearly all portability bugs.

Fair point.  But you'll get shouted down just for raising this ...

> And for the more obscure architectures, virtually all of the testing
> comes from the build of the package.  How many people out there are
> actually using e.g. KDE on mips enough to actually find any portability
> bugs?

That is an important point, and nobody else really picked it up. Almost all 
other contributors to this thread engaged in attempts to stifle the debate 
and claim "that the parrot wasn't dead, but resting". 

But to the best of my knowledge, Marco's (blog) post from a few months 
ago which showed download from ftp.it.debian.org by architecture stands 
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 
are no KDE users on mips.  So guys, we need a new framework.

Maybe we should pick up on Petter's suggestion of stricter buildd requirements. 
Maybe we should only build base and essential packages for the minor 
architectures [ after, apt-source is there for everybody to go further ]. We
can still provide the debian-installer for everything with a power cord 
provided we have the resources to code, maintain, debug, document, improve, ...
and all those platforms.

Dirk