From Fedora Project Wiki

< SIGs‎ | KDE

Fedora & KDE Creating a Stable World

The gist of this proposal was discussed at FUDCon 2009 by those in attendance from the KDE-SIG. They are Ben Boekel(mathstuf), Jaroslav Reznik(jreznik), Rex Dieter(rdieter) and Steven Parrish(SMParrish)

Background

Currently we are updating all available Fedora releases, with every release from upstream KDE.

This has several drawbacks.

  • Package churn. Both the Fedora Board and FESCO had expressed concern over the number of updates to our packages. This situation is likely to get worse in the future as our current monolithic packages are spit into multiple components. This split is necessated by the creation of a KDE Netbook set of packages, and also to get some requested KDE apps into their own packages.
  • Maintainer time. The affore mentioned split of packages will require more time from the maintainers. If we continue to do the work to keep all KDE releases in all active Fedora releases we are stretching our resources to fine. Maintainers should be devoting there time to issues with the current release and Rawhide.
  • Stability. As a Fedora release ages it becomes more stable. This stability is something that users appreciate and want in their systems. By introducing a new KDE release late in the game we can introduce instability in the system, and leave ourselves little time to correct the issues.


The Proposal

The proposal as discussed at FUDCon is as follows.

  • Only 1 Major KDE upgrade per release
  • Once Rawhide has gone to Alpha, we stop pushing any updates of KDE packages with the exception of serious bug fixes (time permitting). This applies to the soon to be EOL release only.


The benefits

  • More time for developers to work on making the current release stable and to work on the latest and greates for Rawhide.
  • Lets users know in advance what to expect during a release cycle.
  • Will encourage users who want the latest and greatest to stay current with the Fedora releases.
  • Will create some low hanging fruit in the way of backporting specific fixes into the older releases. These will be some good junior jobs that can be showcased to get new people onboard the KDE SIG, or to provide those already in the SIG but who are maybe not packagers a way to help.


The cons

  • User expectations of always getting the latest and greatest.