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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
