SIGs/KDE/Update policy

From FedoraProject

< SIGs | KDE(Difference between revisions)
Jump to: navigation, search
(Process)
 
(Our update process)
Line 6: Line 6:
 
== 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.
1. the new 4.x packages are built for Rawhide
+
* the new 4.x packages are built for Rawhide
2. packages are pushed to kde-unstable repository
+
* packages are pushed to kde-unstable repository
3. input is requested from the first testers
+
* input is requested from the first testers
4. bug tracker is created to collect 4.x bugs and known regressions
+
* bug tracker is created to collect 4.x bugs and known regressions
5. once most of bugs are fixed -> go/no-go meeting (kde sig meeting)
+
* once most of bugs are fixed -> go/no-go meeting (kde sig meeting)
6. update is pushed to updates-testing repository (usually for a few weeks)
+
* update is pushed to updates-testing repository (usually for a few weeks)
7. we closely tracking bugs and regressions - we have lot of testers
+
* we closely tracking bugs and regressions - we have lot of testers
8. once most of bugs/criticals are fixed -> stable go/no-go meeting
+
* once most of bugs/criticals are fixed -> stable go/no-go meeting
9. final updates push
+
* final updates push

Revision as of 15:53, 7 September 2010

Fedora KDE Plasma Desktop update policy

We are asking for exception to ship 1 4.x update in Fn release.

Reasons

Our update process

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

  • the new 4.x packages are built for Rawhide
  • packages are pushed to kde-unstable repository
  • input is requested from the first testers
  • bug tracker is created to collect 4.x bugs and known regressions
  • once most of bugs are fixed -> go/no-go meeting (kde sig meeting)
  • update is pushed to updates-testing repository (usually for a few weeks)
  • we closely tracking bugs and regressions - we have lot of testers
  • once most of bugs/criticals are fixed -> stable go/no-go meeting
  • final updates push