On Fri, Mar 26, 2004 at 08:07:10PM +0000, Andrew M.A. Cater wrote: > On Fri, Mar 26, 2004 at 07:00:23AM +0000, Andrew M.A. Cater wrote: > > On Thu, Mar 25, 2004 at 09:58:19PM -0800, Adam McKenna wrote: > > > On Thu, Mar 25, 2004 at 05:53:34PM -0800, Russ Allbery wrote: > > > > It's exactly the desktop software that often has > > > > very long dependency chains that are difficult to get into a releasable > > > > state at the same time. > > > > > > ...yet all of the other Linux distributors seem to be able to do it. > > > > > > --Adam > > Nope. Red Hat 9 - i386 only > > Fedora - i386/ia64 > > SuSE 9.1 i386/ia64/AMD ?? > > See any Alpha / SPARC / m68k ?? > No, and I could care less about them. If our releases are being delayed > because we're spending too much time supporting dead platforms, Which platforms are you singling out as the dead ones? Using what criteria? Other than a lack of a viable installer for a few of the ports at present, there are no ports I see which stand out as being particularly less useful or releasable than the others, and certainly not any that are consistently so over time. The issue is not the quality of the ports, it's the *number* of them. Coordinating 6 or 11 ports takes more effort than coordinating 2 of them, regardless of which architectures they are. People are happy to argue for dropping "doorstop architectures" or "dead platforms" to get us to a release, but there's no real evidence that any of the existing ports meet objective criteria that would justify excluding them from the release. Well, in medical science one of the standards for being "dead" is brain death; so maybe we should evaluate dropping the i386 port, too, on the grounds that it's a brain-dead processor design? > we should drop support for them in our releases, or at least support > them as secondary platforms which are released after the primary > platforms. But if coordinating 11 architectures takes more work than coordinating 2, maintaining 11 architectures *without* coordinating them takes even more. I don't think it's at all realistic to support these other architectures in Debian stable if they're not going to release together. Now, maybe 11 architectures is simply too many to coordinate and still be able to release at intervals that are acceptable to Debian as a whole. If this is true (and I'm not personally persuaded of this yet, though I do recognize that all other things being equal, increasing the number of archs will slow down a release), it's something we'll have to address. I'm not sure how it could be addressed without dropping architectures altogether. > > Also generally less than half the size of Debian unstable / > > testing or (perhaps with the exception of SuSE) stable. > > Enterprise editions may have - RH doesn't have Alpha / SPARC now - > > but it's generally a release or so behind. Debian is also a > > volunteer organisation. > The fact that Debian is a volunteer organization has nothing to do with the > fact that we release slowly. I wish people would stop using this red herring > argument. We probably have more manpower than the development teams of the 3 > largest Linux distributors put together. The problem, as in most large, > ineffective organizations, is in management. Given that d-i has been the holdup for some time, and is only now finding its way into a truly usable and releasable state as of the latest beta, I wonder what sort of managing you would like to see beyond the repeated requests for volunteers to help with the installer? I don't see that you've committed any code to the debian-installer SVN repo, and I don't see that you've filed any current installation reports regarding the installer (though I do see you're subscribed to the debian-boot list, and must have done at least one test install -- so thank you for that!). What "management techniques" would entice you to do more to ensure our installer is releasable? -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature