Re: Let's remove mips, mipsel, s390, ...

[Brian Nelson <pyro@debian.org>]

Dirk Eddelbuettel <edd@debian.org> writes:

> Brian Nelson <pyro <at> debian.org> writes:
>> 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. 

As long as the fringe architectures are not slowing down releases, and
the mirrors have the bandwidth and disk space for them, I don't have a
problem keeping them around.  I have yet to see anyone give a compelling
reason to keep them, but if they aren't hurting anyone, who cares?

However, I do think that not including amd64 (while keeping mips and
friends) in the sarge release due to mirroring problems is ridiculous.

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

It's not clear to me how much supporting all of these arches delays our
releases.  I believe that some delay is inherent, but I'm skeptical
whether it's significant compared to other sources of delay.

I don't recall ever hearing a RM state that supporting all of these
arches was slowing down the release cycle.  And I think that's
significant.

The real problem seems to me, aside from the mysterious difficulties of
setting up testing-security and t-p-u, seems to be that it's very hard
to consistently keep the flow of packages into testing.  There are too
many inter-dependencies, packages are uploaded too frequently, and bugs
appear at too great of a rate.  Or at least that's my impression as an
outside observer.

Portability and buildd problems undoubtedly play a role in there, but I
suspect it's a relatively minor role.  Can someone more involved in the
release process confirm or deny this?

-- 
Society is never going to make any progress until we all learn to
pretend to like each other.