KDE vs. GNOME on F10

[Kevin Kofler]

Matthias Clasen wrote:
> - It would pull along a good-sized portion of the 'plumbing' layer: new
> udev, kernel, pulseaudio, X...

Hmmm, that's interesting. KDE seems to be a lot more flexible there, you 
sure don't need to run the latest kernel to use the latest KDE.

That said, some stuff like the kernel has traditionally been updated 
frequently anyway (though lately there have been issues), other stuff like 
PulseAudio could probably use getting updates too (as they fix bugs, though 
AIUI most bugfixes are in ALSA, which brings us back to the kernel).
 
> - We don't have the man power to do a good job on this. This may be
> different on the KDE side.

:-)

I'll remember this in case you argue about KDE SIG's supposed lack of 
manpower in the future. :-p

That said, …

> While we do a good chunk of the development work for each GNOME release,
> the KDE sig is more of a packaging effort, as far as I understand. Correct
> me if I'm wrong here...

… you have a point here.

Another factor is that KDE's big modules are a lot less work to package than 
the many small modules GNOME ships.

> - It is not compatible with the concept of a finished, stable release.
> If we just want to dump all the latest stuff in there, why bother with
> freezes and releases at all ? We could all just use rawhide...

In KDE SIG, we don't dump "all the latest stuff" in there. First of all, 
version upgrades always go to updates-testing first, we don't just dump them 
to updates. They'll stay in updates-testing as long as needed to hunt down 
any regressions, for example Qt 4.5 stayed there for quite a long time. 
We'll only push something to stable when we're convinced it actually IS 
stable. And we also don't push out everything as updates. We do NOT push:
* prereleases of core KDE or of most applications (only few exceptions), we 
push only releases upstream deems stable,
* major (first digit) updates like KDE 3->4, Amarok 1->2 and other KDE 3->4 
ports of applications with major changes and known regressions,
* any other stuff we do not consider ready for the average user's 
consumption.

Just look at the contents of kde-redhat unstable (http://apt.kde-
redhat.org/apt/kde-redhat/fedora/11/i386/RPMS.unstable/) for examples of 
stuff we do NOT push as updates to stable releases (whereas Rawhide has it). 
Currently, kde-redhat unstable for F11 contains Digikam 1.0 Beta 3 (unstable 
prerelease), Eigen2 2.0.3 (already in stable updates, can be removed now), 
K3b 1.66 (unstable prerelease, and a KDE 4 port with major changes), 
Kaffeine 1.0-pre1 (likewise), a new kde-plasma-stasks build (fixes for KDE 
4.3, will be pushed with our 4.3 updates most likely), KOffice 2.0.1 (KDE 4 
port with major changes), Konversation 1.2 alpha4 (unstable prerelease, and 
a KDE 4 port with major changes) and builds of Qt and Phonon which enable 
Qt's own copy of Phonon (still shipped as a system library, of course, just 
built from the Qt SRPM now as that's actually more up to date than the 
tarball and as building it together with Qt has other benefits, in 
particular, it avoids a circular dependency when building QtWebKit; this is 
in kde-redhat unstable because it also makes Phonon-GStreamer the default 
rather than Phonon-Xine). All that stuff is already in Rawhide (also hoping 
that the prereleases will be sufficiently stable by the time F12 releases).

        Kevin Kofler