Re: kdebase, kdemultimedia ETAs?
On Mon, Jan 05, 2004 at 03:26:27PM -0600, Chris Cheney wrote:
> On Mon, Jan 05, 2004 at 09:55:49PM +0100, Dominique Devriese wrote:
> > I think we all would very much like KDE 3.2 in sarge. I have a newly
> > added application in there e.g., that deserves more attention.
> > However, we have to make a concession at some point, and we have to
> > keep Debian's interests in mind. If other Debian devs see that KDE
> > gets to upload a brand new version, they'll want to do the same, and
> > we can write off all chances to a quick Debian release.
I fully agree with Nathanael's position here. Uploading KDE 3.2 at this
point will probably kill your chances of getting a working KDE in sarge,
or else delay sarge radically, since the version of KDE in testing is
not currently releaseable. (An installable kdemultimedia would have got
into testing tonight if it weren't for the recent upload; fortunately it
narrowly escaped screwing over newer versions of
jack-audio-connection-kit and alsa-lib, which are needed for GNOME.
There are a lot of interdependencies which still need to be resolved.)
I'd suggest that KDE ought to be in mini-freeze (bug fixes, no new major
upstreams) until no KDE packages are listed in
http://ftp-master.debian.org/testing/testing_probs.html and in
particular until a modern version of meta-kde is in testing. I'm giving
the GNOME people essentially the same advice. We *really* need to have
stable, working, installable (!) versions of the desktop environments in
testing, and we need them there as soon as possible. The way to do that
is to fix, stabilize, and freeze, not introduce lots of new code.
> Another thing to note was that the toolchain was supposed to have been
> frozen in September but there was a new gcc upload just last week on
> 29 Dec 2003... As long as even the toolchain isn't frozen freezing
> other things aren't going to work very well either, for example see the
> kdebase breakage wrt SYS_sysinfo. AFAICT that was broken by new glibc
> with 2.6 headers. Yes, using syscalls the way KDE did was not a good
> idea, but if the toolchain is going to continue to rev exposing more
> bugs in applications what is the point in the freeze? I don't know if
> anyone with power is reading this, but freezing the toolchain at some
> point would be a good idea.
I don't think there are going to be any more major toolchain changes
from now until release. However there does still have to be *some* work
done on gcc to fix compiler bugs exposed by builds. As far as I know,
this has been the driver for virtually all Debian gcc package work over
the last few months. There don't have to be no changes at all to the
toolchain: common sense applies, and "no major destabilizing changes,
but bug-fixes allowed" is the sense we're looking for.
The linux-kernel-headers change was *months* ago, hitting unstable at
the end of October; I think, frankly, that now is long past the time
when it's legitimate to still be worrying about that. No offence
intended, but how long did it take to get kdebase fixed for that change?
A month and a half or so?
> > Therefore, I would argue that at the time of the KDE 3.2 upstream
> > release, we evaluate sarge's progress, and if it seems likely that it
> > would make a release within, say, a month, then I think we should give
> > the Debian guys that chance.
>
> KDE 3.2's upstream release is less than 2 weeks away... but yes I will
> get kdebase/kdemultimedia fixed and uploaded before then. However, I
> don't promise to wait until they filter into sarge before uploading KDE
> 3.2, since (afaik) currently nothing is filtering into sarge.[0]
This isn't true; we've had a fair amount of activity in sarge. You can
see the last day's activity for yourself at
http://ftp-master.debian.org/testing/update_output.txt.gz, rather than
guessing.
> [0] I suppose arch all packages can filter into sarge but since several
> buildds are very behind and/or not working at all arch any are taking
> a very prolonged time to even get built. And if packages aren't built on
> all archs then they obviously can't migrate to sarge.
Anthony explicitly allowed arm, s390, and sparc to slip while their
build daemons were behind.
Cheers,
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: