There's a release of GNOME 2.27.90 scheduled for this week, which means that GNOME will enter a code freeze. This is the point where I usually pick up packaging the next major version. For GNOME 2.27/28, some things will change in the distribution: - DeviceKit-Disks (new package) - PolicyKit 1.0 replacing 0.9 - PulseAudio (new package) - Esound DeviceKit-Disks will replace the functionality that used to be provided by hal. GNOME will no longer use hal for this. I don't know about KDE, but I think they will follow soon. Hal will stay alive, but it has received deprecation status upstream, which means that only bugfixes will get applied, no new features anymore. My plans are to replace PolicyKit 0.9 with 1.0 completely. Yes, they can be installed side-by-side, but I don't like to have a deprecated policy framework on my system. Any application depending on PolicyKit needs to be ported. Fedora has patches available for most of them. In case of KDE and GNOME: both support PolicyKit 1.0 in the latest versions, KDE 4.3 and GNOME 2.27/28. The only package that I know of not supporting PolicyKit 1.0 is hal. Hal will get a special treatment: removal of PolicyKit interaction. The next version of hal will use an at_console ruleset. ConsoleKit has backwards compatibility for this. I don't want to return to the group setup we had before. Since Udev 145 will use ACLs once our initscripts mount /dev/ on tmpfs instead of ramfs, a ConsoleKit login will create ACLs for access to devices on /dev. This means users don't have to be member of any group to listen to sound, use DRI or write CDs once this is changed. Enforcing group membership to hal users would be a stupid thing to do then. Then there's PulseAudio. Though I still don't feel the need for this one on the systems I own, a lot of users have requested this. PA has matured a lot in the meanwhile, and PA is more than just an ordinary ESD replacement. Another issue is ESD. This package is not really maintained upstream anymore, and I don't think it makes sense to have two sound servers as dependency for one desktop. Given the fact that Fedora disables esound support since 2.23.4, I think it won't be a problem to remove it from the dependency chain. Esound will stay in the repositories, but won't be used by GNOME as sound server anymore.