On Wed, Jul 23, 2003 at 06:59:53AM +0100, John Gay wrote: > This brings up something I've been thinking about for a while now: > > With the long release cycles of Debian, and especially the way it > always seems to be poorly timed with other major releases, I.E. KDE, > XFree86, Gnome etc, maybe the Debian people should look at spitting > the releases up to allow a more up-to-date Debian.
This comes up about once a month somewhere. Not only do we not even remotely have the infrastructure to release parts of the system independently, but I suspect that there would be a significant loss of efficiency due to the overheads of trying to manage multiple releases, what with the relatively small number of people working on release issues. Also, I think the complexity of library dependencies precludes splitting the system up this way. Take, for instance, the situation at the moment where the kdelibs breakage prevents kdepim being updated in testing; a new kdepim is needed in testing in order to avoid being broken by the new version of pilot-link; the new version of pilot-link is needed for the new version of gnome-pilot; and the new version of gnome-pilot is needed in order to work with the new version of control-center. Thus constructing a consistent system from what we've got actually requires a fixed kdelibs in order for some parts of GNOME to be updated! What would you do if this happened between two parts of a split release and the other part wasn't scheduled to be released until six months down the line. The current testing distribution is *very* good at spotting these kinds of problems, and releasing without those problems is a major feature of Debian releases. If you attempt to split up the releases, I honestly believe that it will be impossible to keep that consistency, because you will end up saying "oh, we just need to release KDE over there in order to release a version of base which doesn't break everything else", and before you know it you're straight back to the current system. The answer to our release problems is not to jiggle releases around in an attempt to avoid having to fix packages so quickly, but to keep packages in a working state as much as possible (e.g. KDE hasn't been releasable even on its own for several continuous months, and is only now beginning to approach that state). That benefits both our users and our release cycle. > Rather than releasing the entire system at one time, and then working > on the next entire system, they could split it into major sections > like: Base, XFree86, KDE, Gnome, etc. Each would work on building > against the current stable version of the rest of the system. After > all, KDE is releasing KDE-3.1.2 debs for stable, Brandan, Daniel Stone > and others are releasing up-dated XFree86 packages for stable. Adrian Bunk has a disclaimer in his stable backport repository that he can't guarantee the safe operation of his packages with any other backport repositories. He has an entirely fair point here, I think; dealing with Debian unstable on its own is relatively easy, but dealing with a forest of independent repositories is a maintenance nightmare. Cheers, -- Colin Watson [EMAIL PROTECTED]
