From Fedora Project Wiki
(→Background: Comment on some of the points.) |
m (Spelling/typo fixes.) |
||
| Line 2: | Line 2: | ||
The gist of this proposal was discussed at FUDCon 2009 by those in attendance from the KDE-SIG. | The gist of this proposal was discussed at FUDCon 2009 by those in attendance from the KDE-SIG. | ||
They are Ben | They are Ben Boeckel (mathstuf), Jaroslav Řezník (jreznik), Rex Dieter (rdieter) and Steven Parrish (SMParrish) | ||
== Background == | == Background == | ||
| Line 12: | Line 12: | ||
* 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. | * 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 | * 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 | ** 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 | ||
| Line 29: | Line 29: | ||
=== The benefits === | === The benefits === | ||
* More time for developers to work on making the current release stable and to work on the latest and | * 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. | * Lets users know in advance what to expect during a release cycle. | ||
Revision as of 21:44, 14 December 2009
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 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 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.
The cons
- User expectations of always getting the latest and greatest.