SIGs/KDE/Stability Proposal

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 Boeckel (mathstuf), Jaroslav Řezník (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 aforementioned 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.
  • But it takes very little more time to build for 2 current releases than one and worst case I'm willing to do the work on my own. -- Kevin Kofler

• 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.
  • Uh, I have been running "previous stable" releases for a while now and have found them to be really stable, the KDE updates haven't caused any problems. -- Kevin Kofler

The Proposal

The proposal as discussed at FUDCon is as follows.

• Only 1 4.n 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 greatest 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.

• KDE updates often also need an updated Qt; for example updating to KDE 4.4 means that Qt has to be updated to 4.6. As more and more applications are written with Qt, pushing out Qt updates to older Fedora branches might destabilize a lot of non-KDE apps (or at least create maintainer burden).

The cons

• User expectations of always getting the latest and greatest. Feedback to a proposal similar to this on the fedora-kde mailing list has been overwhelmingly negative. In fact, for several people, version upgrades are the very reason they are using Fedora.
• Developer time savings are not significant, as most of the work on the new versions needs to be done anyway for the current release and/or Rawhide.
• Users already know what to expect with the current system: upgrades to the current versions of the KDE SC until EOL. That translates to roughly 13 months of upgrades and includes 2 minor (4.n.0) and approx. 9 bugfix (4.m.n) releases (one for each of the 13 months - the 2 4.n.0 releases - the 2 4.n.5 releases upstream isn't doing anymore). The proposed new system would just introduce more uncertainty.
• Most bugfixes will most likely end up never getting backported. As upstream doesn't support old branches, upgrading to the current branch is the only way to continue directly providing upstream bugfixes. Backporting is a lot of work and, while every single bugfix might be a "low-hanging fruit", backporting all of them is a huge task and just not going to happen.
• The only issues early adopters of Qt 4.6 reported (except for one single report about in-house apps we don't have access to and can't really support) were with applications included in the KDE SC 4.3.x itself, KDE 4.4 will fix those problems. There seems to be no widespread breakage of Qt-only or third-party KDE apps.