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. > 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. But a total of > eleven is insane. > But then it doesn't matter anymore. These days, Debian is "infrastructure". > We no longer make releases. We provide the basis from which others make releases > -- Ubuntu, Prodigy, Knoppix, Custom debian dists etc pp. Any maintainer who believes that trying to release "doesn't matter" is invited to file serious bugs against all his optional/extra packages so that the release team can remove them from testing outright rather than worrying about whether they're in a releasable state. The more people believe that releasing does not matter, the longer it takes the rest of us to pull off a release. > Still, the hours we maste on fixing, building, maintaining, ... code on unused > platforms is hysterical waste of resources. Resources we don't really have. 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. The four most common porting problems for software are endianness (differs between i386/amd64 and powerpc), word size (differs between i386/powerpc and amd64), char signedness (differs between i386/amd64 and powerpc), and use of non-PIC code in shared libs (which is a problem on *all* non-i386 platforms). A fifth, less significant portability issue involves arm-specific weirdness with floating point handling, which affects only a handful of packages that try to do their own direct manipulation of floats. So which portability problems are the ones that we waste time fixing code for? I certainly don't think that maintainers/packages should be penalized for failures of porters to provide viable build infrastructure for their architectures, and I think that we should have stricter standards in this area for etch; but the actual amount of work that maintainers have to do to their packages that's only of benefit to a single, little-used architecture is negligible. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature