Re: Qt versioning (was: KDE 3.1.2 broken)
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 [cjwatson@flatline.org.uk]
Reply to: