From Fedora Project Wiki

< SIGs‎ | KDE

No edit summary
No edit summary
 
(12 intermediate revisions by 7 users not shown)
Line 1: Line 1:
= Fedora KDE Plasma Desktop update policy =
{{autolang|base=yes}}


We will be shipping one major update per Fedora release. This update will include not only bug & security fixes but new features as well.
= Fedora KDE update policy =
We will be shipping at least two major (6.x.0) updates for Plasma Workspaces, Applications, and Platform/Frameworks per Fedora release. This update will include not only bug & security fixes but new features as well. The general Fedora updates policy is at [[Updates_Policy]]


== Reasons ==
== Reasons ==
 
* Upstream release schedule: it's somewhere in the middle of Fedora release timeframe
* upstream release schedule - it's somewhere in the middle of Fedora release timeframe
* 6.x.y is the only stable and supported version by upstream
* 4.x.y is the only stable and supported version by upstream
** It's not easy to backport bug fixes in a such complex codebase
** it's not easy to backport bug fixes in a such complex codebase
* Users visible changes are slowing down quickly with higher 6.x releases
* users visible changes are slowing down quickly with higher 4.x releases


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


This has several drawbacks.
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.
* 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 split into multiple components. This split is necessitated by the creation of a KDE Netbook set of packages, and also to get some requested KDE Applications 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.
* 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 their 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.
* 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.


== Our update process ==
== Our update process ==
Our update process is quite complex to assure quality of final -> stable push.
Our update process is quite complex to assure quality of final -> stable push.


* the new 4.x packages are built for Rawhide
* the new 6.x packages are built for Rawhide
* packages are pushed to kde-unstable repository
* packages are pushed to [https://copr.fedorainfracloud.org/coprs/g/kdesig/kde/ @kdesig/kde COPR repository]
* input is requested from the first testers
* input is requested from the first testers
* bug tracker is created to collect 4.x bugs and known regressions
* bug tracker is created to collect 6.x bugs and known regressions
* once most of bugs are fixed -> go/no-go meeting (kde sig meeting)
* once most of bugs are fixed -> update is pushed to updates-testing repository
* update is pushed to updates-testing repository (usually for a few weeks)
* we closely tracking bugs and regressions - we have lot of testers
* we closely tracking bugs and regressions - we have lot of testers
* once most of bugs/criticals are fixed -> stable go/no-go meeting
* once most of bugs/criticals are fixed -> final updates push
* final updates push


== The Plan ==
== The Plan ==
* When Fedora releases we will continue to push 6.x.(y+1) releases through normal updates-testing and updates repos. These releases contain only bug and security fixes and should go out to all users.


* When Fedora releases we will continue to push 4.x.(y+1) releases through normal updates-testing and updates repos.  This releases contain only bug & security fixes and should go out to all users.
* When KDE releases the new 6.(x+1).y version this will follow the above '''Update Process'''. However this update will only be made available to users of the current Fedora release.
 
* When KDE release the new 4.(x+1).y release this will follow the above '''Update Process'''. However this update will only be made available to users of the current Fedora release via an optional Fedora repo that the user must enable.  This will allow the user to decide if they wish to install the update.


* Users of previous Fedora releases and those who do not install this optional update will need to understand that there will be no further updates to KDE during the life of this Fedora release. Exceptions will be for bug and security fixes that the KDE-SIG is able to backport.
* Users of previous Fedora releases need to understand that there will be no guarantee of further updates to KDE during the life of this Fedora release. Exceptions will be for bug and security fixes that the KDE-SIG is able to backport.

Latest revision as of 15:40, 18 June 2024

{{lang|en|es|page=SIGs/KDE/Update policy/}

Fedora KDE update policy

We will be shipping at least two major (6.x.0) updates for Plasma Workspaces, Applications, and Platform/Frameworks per Fedora release. This update will include not only bug & security fixes but new features as well. The general Fedora updates policy is at Updates_Policy

Reasons

  • Upstream release schedule: it's somewhere in the middle of Fedora release timeframe
  • 6.x.y is the only stable and supported version by upstream
    • It's not easy to backport bug fixes in a such complex codebase
  • Users visible changes are slowing down quickly with higher 6.x releases

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 split into multiple components. This split is necessitated by the creation of a KDE Netbook set of packages, and also to get some requested KDE Applications 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 their 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.

Our update process

Our update process is quite complex to assure quality of final -> stable push.

  • the new 6.x packages are built for Rawhide
  • packages are pushed to @kdesig/kde COPR repository
  • input is requested from the first testers
  • bug tracker is created to collect 6.x bugs and known regressions
  • once most of bugs are fixed -> update is pushed to updates-testing repository
  • we closely tracking bugs and regressions - we have lot of testers
  • once most of bugs/criticals are fixed -> final updates push

The Plan

  • When Fedora releases we will continue to push 6.x.(y+1) releases through normal updates-testing and updates repos. These releases contain only bug and security fixes and should go out to all users.
  • When KDE releases the new 6.(x+1).y version this will follow the above Update Process. However this update will only be made available to users of the current Fedora release.
  • Users of previous Fedora releases need to understand that there will be no guarantee of further updates to KDE during the life of this Fedora release. Exceptions will be for bug and security fixes that the KDE-SIG is able to backport.