Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Sun, Feb 20, 2005 at 10:57:47PM +0000, Dirk Eddelbuettel wrote:
> Clint Byrum <cbyrum <at> spamaps.org> writes:
> > Now, can someone please tell me how messages like the one below, and
> > others, aren't indicative that debian should drop s390, mipsel, and
> > maybe hppa from the list of architectures? How about we release for
> > i386, sparc, and powerpc, and let the others release on their own
> > schedule? This business of supporting 11 architectures and making sure
> > they're all 100% right before releasing is just about the worst idea
> > ever.
>
> Couldn't agree more.
>
> Our chances of actually releasing one day could only increase if we
> dropped arches such as mipsel, s390, m68k, ... and concentrated on
> those that actually mattered: i386, powerpc, amd64 -- and I'll gladly
> add a few more.
I'll believe that when you can point me to an actual occasion where
something not being built on /only/ one of those "less mattering"
architectures you want to drop (as opposed to the three latter ones)
effectively stalled the release.
As it is, architecture-specific problems occur on all architectures, not
just the "less important" ones. Claiming the contrary only proves you
don't know what you're talking about.
The problem being talked about (not enough disk space on the buildd
host) is serious, but can be fixed; and /nothing/ prevents it from
happening to other architectures in the future.
> 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. It
also ensures that GNU/Linux still actually runs on the platforms we
support, which is often of great importance of embedded developers. It
also ensures that gcc remains working (what better way to test a
compiler than to compile 10G worth of software with it?), and so on.
[...]
> Still, the hours we maste on fixing, building, maintaining, ... code
> on unused platforms is hysterical waste of resources.
The only resource that is being wasted, is one of disk space (well, and
network traffic for mirror updates). How is that a major problem,
considering that mirrors will be allowed to pick their architecture in
the future?
> Resources we don't really have.
On porting, we usually have all the resources we really need.
> It would be better to concentrate on a core of packages, and
> platforms, and then get on with it. One day it will break the
> infrastructure provision, at which point someone will fork our
> high-priority core packages.
You're welcome to do so, if you really must.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Reply to: