[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

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.

Reply to: