Updates Policy

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
m (AutoQA)
(clean up the references)
 
(16 intermediate revisions by 5 users not shown)
Line 2: Line 2:
  
 
Fedora has differing policies for each of its branches. This document describes for maintainers what sort of updates should be created in packages for each of the various branches of existing Fedora. In the event of questions or clarifications, please file a [https://fedorahosted.org/fesco/newticket FESCo trac ticket ] or discuss on the devel list. In general, releases should go from less conservative (rawhide) to more so (the oldest supported stable release). This document attempts to describe when and what kinds of updates maintainers should push to Fedora users of its various branches. The [[Stable release updates vision]] from the Fedora Board includes more high level discussion and philosophy, while this  
 
Fedora has differing policies for each of its branches. This document describes for maintainers what sort of updates should be created in packages for each of the various branches of existing Fedora. In the event of questions or clarifications, please file a [https://fedorahosted.org/fesco/newticket FESCo trac ticket ] or discuss on the devel list. In general, releases should go from less conservative (rawhide) to more so (the oldest supported stable release). This document attempts to describe when and what kinds of updates maintainers should push to Fedora users of its various branches. The [[Stable release updates vision]] from the Fedora Board includes more high level discussion and philosophy, while this  
document is more a practical guide. Refer to [[Package update HOWTO]] for the technical steps on pushing the updates
+
document is more a practical guide. Refer to [[Package update HOWTO]] for the technical steps on pushing the updates. The [[Fedora Release Life Cycle]] provides a more detailed overview of the development process.
  
 
= Rawhide / devel / master =
 
= Rawhide / devel / master =
  
Rawhide is the always-rolling development tree. Package updates built for rawhide are composed every day and pushed out to all rawhide consumers. There are no "updates" or "updates-testing" repositories for rawhide. The Bodhi updates system is not used. New builds against this tree also are added to the build root (ie, other packages build from them) quite often.  
+
[[Releases/Rawhide|Rawhide]] is the always-rolling development tree. Package updates built for rawhide are composed every day and pushed out to all rawhide consumers. There are no "updates" or "updates-testing" [[Repositories]] for rawhide. The [[Bodhi]] updates system is not used. New builds against this tree also are added to the build root (ie, other packages build from them) daily (usually).  
  
repos available: base
+
repos available: [[Repositories#rawhide|''rawhide'']]
  
 
For updates to rawhide packages, Maintainers SHOULD:
 
For updates to rawhide packages, Maintainers SHOULD:
Line 15: Line 15:
 
* '''A week in advance''', notify maintainers who depend on their package to rebuild when there are abi/api changes that require rebuilds in other packages or offer to do these rebuilds for them.
 
* '''A week in advance''', notify maintainers who depend on their package to rebuild when there are abi/api changes that require rebuilds in other packages or offer to do these rebuilds for them.
 
* Use a separate buildsystem tag when dealing with mass builds of many packages, so they can land at the same time. File a ticket with https://fedorahosted.org/rel-eng/newticket for this.  
 
* Use a separate buildsystem tag when dealing with mass builds of many packages, so they can land at the same time. File a ticket with https://fedorahosted.org/rel-eng/newticket for this.  
* Feel free to push out the newest version of packages as long as they do not cause breakage. Also keep in mind that the next Fedora release will be branched off rawhide a few months down the road. Therefore, it is best to only push development releases to rawhide if you are fairly confident that there will be a stable enough release in time for the next Fedora release. Otherwise you may have to back down to an older, stable version after the branching, which may involve epochs and other inconveniences.
+
* Feel free to push out the newest version of packages as long as they do not cause breakage. Also keep in mind when the next Fedora release will be branched off, and be  fairly confident that there will be a stable enough release in time for the next Fedora release. Otherwise you may have to back down to an older, stable version after the branching, which may involve epochs and other inconveniences.
  
 
= Branched release =
 
= Branched release =
  
A branched release exists for part of the development cycle. It is branched off rawhide and eventually becomes the next stable release.  
+
A [[Releases/Branched|Branched]] release exists for part of the development cycle. It is branched off Rawhide and eventually becomes the next stable release.  
Branched releases do use the fedora updates system (bodhi). There are several "phases" that a branched release goes through that affect what updates can and should be done. In general maintainers should keep in mind that this tree is being used to stabilize for the next release, so changes should be careful and considered and heading toward stability. Builds in branched releases are NOT automatically added to the build root. You will need to request a buildroot override for needed packages.  
+
After the [[#Bodhi_enabling|Bodhi enabling]] point, Branched releases do use the update feedback system ([[Bodhi]]). There are several "phases" that a branched release goes through that affect what updates can and should be done. In general maintainers should keep in mind that this tree is being used to stabilize for the next release, so changes should be careful and considered and heading toward stability.
 +
 
 +
== [[Releases/Branched|Branched]], pre-Bodhi enabling ==
 +
 
 +
For a short time after [[Fedora Release Life Cycle|the branch event happens]] but before the [[#Bodhi_enabling|Bodhi enabling]] point, the Branched release works just like Rawhide: builds submitted by packagers are considered [[Repositories#stable|stable]] immediately, and sent to the [[Repositories#fedora|''fedora'' repository]] directly in the next nightly compose. There are no restrictions beyond those for Rawhide at this point, but maintainers SHOULD be thinking about stabilization from this point onwards, and making sure their packages will be in good condition well in advance of the stable release.
 +
 
 +
repos available: [[Repositories#fedora|''fedora'']]
 +
 
 +
== Bodhi enabling ==
 +
 
 +
At the ''Bodhi enabling point'', the [[Bodhi]] update system is enabled for the Branched release. After this point '''for the entire remaining lifetime of the release''', all updates must go through Bodhi before they can be marked ''stable'' and moved to either [[Repositories#fedora|''fedora'']] or [[Repositories#updates|''updates'']]. At present, the ''Bodhi enabling point'' occurs on the day of the [[Milestone freezes|Alpha freeze]], but it is important to remember that they are distinct events: the Alpha freeze lasts until Alpha release, but Bodhi enabling is permanent.
 +
 
 +
repos available: [[Repositories#fedora|''fedora'']], [[Repositories#updates-testing|''updates-testing'']]
  
 
== Pre Beta ==
 
== Pre Beta ==
  
This is the time between the branch from rawhide and the Beta release of the new branched OS. During this time we are attempting to stabilize  
+
This is the time between the ''Bodhi enabling point'' and the Beta release. During this time we are attempting to stabilize the major versions of software that will be shipped with the final release of the OS. Major updates can be tolerated, but breaking things for early testers should be avoided if possible. Additionally, as we get close to Alpha or Beta releases any change that breaks composes of Live media, install media or testing should be avoided. Packages for [[Changes]] should be landing and getting major testing.  
the major versions of software that will be shipped with the final release of the OS. Major updates can be tolerated, but breaking things for early  
+
testers should be avoided if possible. Additionally, as we get close to Alpha or Beta releases any change that breaks composes of Live media, install media or testing should be avoided. Packages for Features should be landing and getting major testing.  
+
  
repos available: base updates-testing
+
repos available: [[Repositories#fedora|''fedora'']] [[Repositories#updates-testing|''updates-testing'']]
  
During this time Maintainers MUST (enforced by bodhi):
+
From this point onwards Maintainers '''MUST'''<ref name="must">''Must'' requirements are enforced by Bodhi.</ref>:
  
 
* Push all updates first to updates-testing.  
 
* Push all updates first to updates-testing.  
Line 38: Line 48:
 
and Maintainers SHOULD (not enforced):  
 
and Maintainers SHOULD (not enforced):  
  
* Avoid ABI/API changes where possible. If unavoidable, should coordinate a side tag to rebuild packages in or a mass build/update. ( file a rel-eng ticket at https://fedorahosted.org/rel-eng/newticket)
+
* Avoid ABI/API changes where possible. If unavoidable, should coordinate a side tag to rebuild packages in or a mass build/update, by filing a [https://fedorahosted.org/rel-eng/newticket releng ticket].
 +
 
 +
=== Milestone freezes ===
 +
 
 +
During this period there are two [[Milestone freezes]], ''Alpha freeze'' and ''Beta freeze''. Each is scheduled to run for the two weeks leading up to the release date (and in fact lasts until the release is signed off, even if it is delayed). During these times, builds will not be marked ''stable'' and moved from [[Repositories#updates-testing|''updates-testing'']] to [[Repositories#fedora|''fedora'']] (and hence included in the milestone release composes) except for those approved under the [[QA:SOP_blocker_bug_process]] or [[QA:SOP_freeze_exception_bug_process]]. Once the milestone release is made, these freezes are lifted. These freezes are technically not a part of the Updates Policy, but are briefly mentioned here for clarity. The [[Milestone freezes]] page provides more details and is the canonical reference in case of any conflict.
  
 
== Beta to Pre Release ==
 
== Beta to Pre Release ==
  
This is the time between the Beta release and the final release as stable of the branched OS. The branched OS should now be stabilized and prepared for release. Major changes should be avoided during this period.  
+
This is the time between the Beta release and the [[Milestone freezes|Final freeze]]. The branched tree should now be stabilized and prepared for release. Major changes should be avoided during this period. Bear in mind that in most cases, the state your package has reached in the stable [[Repositories#fedora|''fedora'']] repository at the time of the Final freeze is the state it will be in for the final release.
  
repos available: base updates-testing
+
repos available: [[Repositories#fedora|''fedora'']] [[Repositories#updates-testing|''updates-testing'']]
  
During this time maintainers MUST:  
+
From this point onwards maintainers '''MUST'''<ref name="must" />:  
  
 
* Avoid Major version updates, ABI breakage or API changes if at all possible.  
 
* Avoid Major version updates, ABI breakage or API changes if at all possible.  
Line 55: Line 69:
 
== Pre release ==
 
== Pre release ==
  
During this time the release is being composed and all non blocker changes should be avoided. In pre release period are non-blocker packages queued for so called zero day updates. These packages will be available in updates repository after whole distribution is released.
+
This is the time after the [[Milestone freezes|Final freeze]]. During this time the release is being composed and only packages granted exceptions through the [[QA:SOP_blocker_bug_process]] or [[QA:SOP_freeze_exception_bug_process]] are marked as ''stable'' and moved to the [[Repositories#fedora|''fedora'' repository]]. The [[Repositories#updates|''updates'']] repository is enabled at some point during this time, and packages other than freeze exception / blocker fixes are queued for so called "zero day" updates, meaning they will be available in the ''updates'' repository at the time of the release (day zero).
  
repos available: base updates updates-testing
+
repos available: [[Repositories#fedora|''fedora'']] [[Repositories#updates|''updates'']] [[Repositories#updates-testing|''updates-testing'']]
  
* All updates pulled into the release MUST fix a blocker.  
+
During this period:
* Push updates first to updates-testing.
+
 
* All [[Critical_path_package | critical path]] updates MUST either have a sum of +2 karma, OR spend at least 14 days in updates-testing and have no negative karma.  
+
* All updates pulled into the release '''MUST'''<ref name="must" /> fix an accepted blocker or freeze exception bug.  
* All non critical path updates MUST either reach the prescribed karma level for that update, OR spend at least 7 days in updates-testing before being allowed in stable.  
+
* All update pushes will go to updates-testing.
* Once, updates repo is available, stable updates will go there instead of to the base OS repo.
+
* All [[Critical_path_package | critical path]] updates '''MUST''' either have a sum of +2 karma, '''OR''' spend at least 14 days in updates-testing and have no negative karma.  
 +
* All non critical path updates '''MUST''' either reach the prescribed karma level for that update, '''OR''' spend at least 7 days in updates-testing before being allowed in stable.  
 +
* Once the ''updates'' repository is available, builds marked as [[Repositories#stable|''stable'']] will go there instead of to [[Repositories#fedora|''fedora'']].
  
 +
<references/>
 
= Stable Releases =
 
= Stable Releases =
  
Line 77: Line 94:
 
Whenever possible packagers should work with upstream to come up with stable branch releases or common patches for older releases, particularly when rebasing would require large dependency chain updates.
 
Whenever possible packagers should work with upstream to come up with stable branch releases or common patches for older releases, particularly when rebasing would require large dependency chain updates.
  
repos available: base updates updates-testing
+
repos available: [[Repositories#fedora|''fedora'']] [[Repositories#updates|''updates'']] [[Repositories#updates-testing|''updates-testing'']]
  
 
== Updates to 'critical path' packages ==
 
== Updates to 'critical path' packages ==
  
 
Updates that constitute a part of the 'critical path' package set (defined
 
Updates that constitute a part of the 'critical path' package set (defined
below) '''including security updates''' must follow the rules as defined for [[Critical path package|critical path packages]] for
+
below) '''including security updates''' MUST follow the rules as defined for [[Critical path package|critical path packages]] for
 
pending releases, meaning:
 
pending releases, meaning:
  
Line 92: Line 109:
 
* The current [[Critical_Path_Packages|critical path package set]]
 
* The current [[Critical_Path_Packages|critical path package set]]
 
* All major desktop environments' core functionality (GNOME, KDE, Xfce, LXDE)
 
* All major desktop environments' core functionality (GNOME, KDE, Xfce, LXDE)
* Package updating frameworks ({{package|gnome-packagekit}}, {{package|kpackagekit}})
+
* Package updating frameworks ({{package|gnome-packagekit}}, {{package|apper}})
* Major desktop productivity apps. An initial list would be {{package|firefox}}, {{package|kdebase}} (konqueror), {{package|thunderbird}}, {{package|evolution}}, {{package|kdepim}} (kmail).
+
* Major desktop productivity apps. An initial list would be {{package|firefox}}, {{package|kde-baseapps}} (konqueror), {{package|thunderbird}}, {{package|evolution}}, {{package|kdepim}} (kmail).
  
Changes to this definition would be done by FESCo or their delegate.
+
Changes to this definition may only be made by [[Fedora_Engineering_Steering_Committee|FESCo]] or their delegate.
  
 
== All other updates ==
 
== All other updates ==
  
All other updates must either:  
+
All other updates '''MUST''' either:  
  
 
* reach the criteria laid out in the previous section '''OR'''
 
* reach the criteria laid out in the previous section '''OR'''
Line 105: Line 122:
 
* spend some minimum amount of time in [[QA:Updates_Testing|updates-testing]], currently one week
 
* spend some minimum amount of time in [[QA:Updates_Testing|updates-testing]], currently one week
  
Package maintainers MUST:  
+
Package maintainers '''MUST''':  
  
 
* Avoid Major version updates, ABI breakage or API changes if at all possible.  
 
* Avoid Major version updates, ABI breakage or API changes if at all possible.  
Line 111: Line 128:
 
* Avoid updates that are trivial or don't affect any Fedora users.
 
* Avoid updates that are trivial or don't affect any Fedora users.
  
Package maintainers SHOULD:
+
Package maintainers '''SHOULD''':
* Push only major bug fixes and security fixes to release(n-1).
+
 
 +
* Push '''only''' major bug fixes and security fixes to the previous stable release (i.e., at present, {{FedoraVersion|long|last}}.
  
 
== Exceptions ==
 
== Exceptions ==
  
Some classes of software will not fit in these guidelines.  If your package does not fit in one of the classes below, but you think it should be allowed to update more rapidly, propose a new exception class to FESCO and/or request an exception for your specific update case. Note that you should open this dialog _BEFORE_ you build or push updates. The following things would be considered in a exception request.  
+
Some classes of software will not fit in these guidelines.  If your package does not fit in one of the classes below, but you think it should be allowed to update more rapidly, propose a new exception class to FESCo and/or request an exception for your specific update case.
 +
 
 +
Note that you should open this dialog '''BEFORE''' you build or push updates. In the event that an issue is raised in the middle of an update already in progress, make sure you turn off autokarma pushes — this can be done while the update is pending in bodhi.
 +
 
 +
The following things would be considered in a exception request.  
  
 
Things that would make it more likely to grant a request:  
 
Things that would make it more likely to grant a request:  
Line 145: Line 167:
 
====  KDE ====
 
====  KDE ====
  
Refer to the following policy for more details
+
Refer to the [[SIGs/KDE/Update_policy|KDE update policy]] for more details
  
https://fedoraproject.org/wiki/SIGs/KDE/Update_policy
+
==== girara and zathura ====
 +
 
 +
These packages are allowed to update in stable releases together.
 +
See https://fedorahosted.org/fesco/ticket/1255
  
 
=== Security fixes ===
 
=== Security fixes ===
Line 191: Line 216:
 
= AutoQA =  
 
= AutoQA =  
  
Note that once [[AutoQA]] is ready, it will be enabled whenever possible. This guide will be modified to add [[AutoQA]] in when it's ready.
+
The [[AutoQA]] automated testing system runs two tests against all updates submitted to Bodhi: a dependency check (to ensure all dependencies of the package(s) can be fulfilled from the repositories) and an upgrade path check (to ensure the update does not break the upgrade path from release to release, i.e. that the update does not contain a package versioned higher than the newest version of the same package available in a later Fedora release). AutoQA adds comments to Bodhi with the results of these test runs. A failure of either test will cause [[Bodhi#Karma_Automatism]] for the update to be disabled (if it was enabled). If you submit an update that fails one of these tests, please check the result and fix the problem. If you are sure the failure is an error in the test rather than an error in your package, you may still manually push the update or re-enable karma automatism.
 
+
== AutoQA Acceptance tests for all updates ==
+
 
+
{{admon/note|This section is not yet enabled in production}}
+
 
+
All updates, including security updates, must pass acceptance criteria before being pushed.
+
 
+
The list of tests will be:
+
* Packages must not break dependencies
+
* Packages must not break upgrade path
+
* Packages must not introduce new file/package conflicts
+
* Packages must be able to install cleanly
+
  
Additional tests will be set by [[FESCo]] with input from [[QA]].
+
AutoQA is (as of 2014-08) being replaced with [[Taskotron]]. Initial Taskotron deployment will work similarly to AutoQA, but the set of tests and level of enforcement may grow in future. The [[QA:Package_Update_Acceptance_Test_Plan]] was written as the original plan for AutoQA update validation, and may still be seen as a framework for future work on Taskotron.
  
 
[[Category:Packaging]] [[Category:FESCo policy]] [[Category:Package_Maintainers]] [[Category:Policy]]
 
[[Category:Packaging]] [[Category:FESCo policy]] [[Category:Package_Maintainers]] [[Category:Policy]]

Latest revision as of 19:40, 25 September 2014

Contents

[edit] Introduction

Fedora has differing policies for each of its branches. This document describes for maintainers what sort of updates should be created in packages for each of the various branches of existing Fedora. In the event of questions or clarifications, please file a FESCo trac ticket or discuss on the devel list. In general, releases should go from less conservative (rawhide) to more so (the oldest supported stable release). This document attempts to describe when and what kinds of updates maintainers should push to Fedora users of its various branches. The Stable release updates vision from the Fedora Board includes more high level discussion and philosophy, while this document is more a practical guide. Refer to Package update HOWTO for the technical steps on pushing the updates. The Fedora Release Life Cycle provides a more detailed overview of the development process.

[edit] Rawhide / devel / master

Rawhide is the always-rolling development tree. Package updates built for rawhide are composed every day and pushed out to all rawhide consumers. There are no "updates" or "updates-testing" Repositories for rawhide. The Bodhi updates system is not used. New builds against this tree also are added to the build root (ie, other packages build from them) daily (usually).

repos available: rawhide

For updates to rawhide packages, Maintainers SHOULD:

  • Try not to push a clearly broken build (breaks the default buildroot package set, etc)
  • A week in advance, notify maintainers who depend on their package to rebuild when there are abi/api changes that require rebuilds in other packages or offer to do these rebuilds for them.
  • Use a separate buildsystem tag when dealing with mass builds of many packages, so they can land at the same time. File a ticket with https://fedorahosted.org/rel-eng/newticket for this.
  • Feel free to push out the newest version of packages as long as they do not cause breakage. Also keep in mind when the next Fedora release will be branched off, and be fairly confident that there will be a stable enough release in time for the next Fedora release. Otherwise you may have to back down to an older, stable version after the branching, which may involve epochs and other inconveniences.

[edit] Branched release

A Branched release exists for part of the development cycle. It is branched off Rawhide and eventually becomes the next stable release. After the Bodhi enabling point, Branched releases do use the update feedback system (Bodhi). There are several "phases" that a branched release goes through that affect what updates can and should be done. In general maintainers should keep in mind that this tree is being used to stabilize for the next release, so changes should be careful and considered and heading toward stability.

[edit] Branched, pre-Bodhi enabling

For a short time after the branch event happens but before the Bodhi enabling point, the Branched release works just like Rawhide: builds submitted by packagers are considered stable immediately, and sent to the fedora repository directly in the next nightly compose. There are no restrictions beyond those for Rawhide at this point, but maintainers SHOULD be thinking about stabilization from this point onwards, and making sure their packages will be in good condition well in advance of the stable release.

repos available: fedora

[edit] Bodhi enabling

At the Bodhi enabling point, the Bodhi update system is enabled for the Branched release. After this point for the entire remaining lifetime of the release, all updates must go through Bodhi before they can be marked stable and moved to either fedora or updates. At present, the Bodhi enabling point occurs on the day of the Alpha freeze, but it is important to remember that they are distinct events: the Alpha freeze lasts until Alpha release, but Bodhi enabling is permanent.

repos available: fedora, updates-testing

[edit] Pre Beta

This is the time between the Bodhi enabling point and the Beta release. During this time we are attempting to stabilize the major versions of software that will be shipped with the final release of the OS. Major updates can be tolerated, but breaking things for early testers should be avoided if possible. Additionally, as we get close to Alpha or Beta releases any change that breaks composes of Live media, install media or testing should be avoided. Packages for Changes should be landing and getting major testing.

repos available: fedora updates-testing

From this point onwards Maintainers MUST[1]:

  • Push all updates first to updates-testing.
  • All critical path updates MUST either get one +1 karma, OR spend at least 14 days in updates-testing and have no negative karma before being moved to stable.
  • All non critical path updates MUST either reach the prescribed karma level for that update, OR spend at least 3 days in updates-testing before being allowed to move to stable.

and Maintainers SHOULD (not enforced):

  • Avoid ABI/API changes where possible. If unavoidable, should coordinate a side tag to rebuild packages in or a mass build/update, by filing a releng ticket.

[edit] Milestone freezes

During this period there are two Milestone freezes, Alpha freeze and Beta freeze. Each is scheduled to run for the two weeks leading up to the release date (and in fact lasts until the release is signed off, even if it is delayed). During these times, builds will not be marked stable and moved from updates-testing to fedora (and hence included in the milestone release composes) except for those approved under the QA:SOP_blocker_bug_process or QA:SOP_freeze_exception_bug_process. Once the milestone release is made, these freezes are lifted. These freezes are technically not a part of the Updates Policy, but are briefly mentioned here for clarity. The Milestone freezes page provides more details and is the canonical reference in case of any conflict.

[edit] Beta to Pre Release

This is the time between the Beta release and the Final freeze. The branched tree should now be stabilized and prepared for release. Major changes should be avoided during this period. Bear in mind that in most cases, the state your package has reached in the stable fedora repository at the time of the Final freeze is the state it will be in for the final release.

repos available: fedora updates-testing

From this point onwards maintainers MUST[1]:

  • Avoid Major version updates, ABI breakage or API changes if at all possible.
  • Push updates first to updates-testing.
  • All critical path updates MUST either have a sum of +2 karma, OR spend at least 14 days in updates-testing and have no negative karma.
  • All non critical path updates MUST either reach the prescribed karma level for that update, OR spend at least 7 days in updates-testing before being allowed to go to stable.

[edit] Pre release

This is the time after the Final freeze. During this time the release is being composed and only packages granted exceptions through the QA:SOP_blocker_bug_process or QA:SOP_freeze_exception_bug_process are marked as stable and moved to the fedora repository. The updates repository is enabled at some point during this time, and packages other than freeze exception / blocker fixes are queued for so called "zero day" updates, meaning they will be available in the updates repository at the time of the release (day zero).

repos available: fedora updates updates-testing

During this period:

  • All updates pulled into the release MUST[1] fix an accepted blocker or freeze exception bug.
  • All update pushes will go to updates-testing.
  • All critical path updates MUST either have a sum of +2 karma, OR spend at least 14 days in updates-testing and have no negative karma.
  • All non critical path updates MUST either reach the prescribed karma level for that update, OR spend at least 7 days in updates-testing before being allowed in stable.
  • Once the updates repository is available, builds marked as stable will go there instead of to fedora.
  1. 1.0 1.1 1.2 Must requirements are enforced by Bodhi.

[edit] Stable Releases

[edit] Philosophy

Releases of the Fedora distribution are like releases of the individual packages that compose it. A major version number reflects a more-or-less stable set of features and functionality. As a result, we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. The update rate for any given release should drop off over time, approaching zero near release end-of-life; since updates are primarily bugfixes, fewer and fewer should be needed over time.

This necessarily means that stable releases will not closely track the very latest upstream code for all packages. We have rawhide for that.

Rebases should be carefully considered with respect to their dependencies. A rebase that required (or provided) a new Python ABI, for example, would almost certainly not be allowed. ABI changes in general are very strongly discouraged, they force larger update sets on users and they make life difficult for third-party packagers. Additionally, updates that convert resources or configuration one way (ie, from older->newer) should be approached with extreme caution as there would be much less chance of backing out an update that did these things.

Whenever possible packagers should work with upstream to come up with stable branch releases or common patches for older releases, particularly when rebasing would require large dependency chain updates.

repos available: fedora updates updates-testing

[edit] Updates to 'critical path' packages

Updates that constitute a part of the 'critical path' package set (defined below) including security updates MUST follow the rules as defined for critical path packages for pending releases, meaning:

  • At the time of the request to stable, the update needs to have either a Bodhi karma sum of 2 OR
  • It must spend at least 14 days in updates-testing AND have no negative Bodhi karma points.

For the purposes of this policy, the 'critical path' package set is defined as the following:

Changes to this definition may only be made by FESCo or their delegate.

[edit] All other updates

All other updates MUST either:

  • reach the criteria laid out in the previous section OR
  • reach the positive Bodhi karma threshold specified by the updates submitter OR
  • spend some minimum amount of time in updates-testing, currently one week

Package maintainers MUST:

  • Avoid Major version updates, ABI breakage or API changes if at all possible.
  • Avoid changing the user experience if at all possible.
  • Avoid updates that are trivial or don't affect any Fedora users.

Package maintainers SHOULD:

  • Push only major bug fixes and security fixes to the previous stable release (i.e., at present, Fedora last.

[edit] Exceptions

Some classes of software will not fit in these guidelines. If your package does not fit in one of the classes below, but you think it should be allowed to update more rapidly, propose a new exception class to FESCo and/or request an exception for your specific update case.

Note that you should open this dialog BEFORE you build or push updates. In the event that an issue is raised in the middle of an update already in progress, make sure you turn off autokarma pushes — this can be done while the update is pending in bodhi.

The following things would be considered in a exception request.

Things that would make it more likely to grant a request:

  • The package is a "leaf" node. Nothing depends on it or requires it.
  • The update fixes a security issue that would affect a large number of users.
  • The update doesn't change ABI/API and nothing needs to be rebuilt against the new version.
  • The update fixes serious bugs that many fedora users are encountering.

Things that would make it less likely to grant a request:

  • The update converts databases or resources one way to a new format.
  • The update requires admin intervention for the service to keep working (config file format changes, etc)
  • The update causes behavior changes (something that was denied is allowed, etc)
  • The update changes the UI the end user sees (moves menus or buttons around, changes option names on command line)
  • The update fixes bugs that no fedora user has reported nor would affect many fedora users (ie, fixes for other platforms or configurations).

[edit] Exceptions list

The following packages have been granted exceptions for the following reasons:

[edit] kernel package

  • Manpower of kernel maintainers prevents us from easily backporting all the bug fixes, security fixes and new hardware enablement we would need to to older, no longer supported kernels.
  • Additionally, multiple kernels can be installed/booted, allowing users to boot older kernels in the event newer ones fail to work, and allowing time for kernel maintainers to fix any critical bugs in new kernels on older stable releases.

[edit] KDE

Refer to the KDE update policy for more details

[edit] girara and zathura

These packages are allowed to update in stable releases together. See https://fedorahosted.org/fesco/ticket/1255

[edit] Security fixes

If upstream does not provide security fixes for a particular release, and if backporting the fix would be impractical, then a package may be rebased onto a version that upstream supports. The definition of practicality is left to the judgment of FESCO and the packager.

[edit] Interoperability

If a package primarily serves to interoperate with hardware or network protocols, and the interface changes, then a package may be rebased if necessary. This includes network games, IM protocols, hardware music players, cell phones, etc. These packages may also be updated to add support for new devices or formats in compatible ways.

Examples of this type of package: Package-x-generic-16.pnglibopenraw, Package-x-generic-16.pnglibimobiledevice, Package-x-generic-16.pngcalibre, Package-x-generic-16.pngpilot-link

[edit] Database packages

Packages like virus scanners and spam filters typically have two components: a rules engine and a database. The database is expected to update frequently (sometimes not through the normal OS update mechanisms), but the rules engine is usually fairly static. However, if the maintained database changes to require a new version of the rules engine, then the package may be a candidate for rebasing.

Examples of this type of package: Package-x-generic-16.pngspamassassin, Package-x-generic-16.pngclamav

[edit] Examples

  • Mozilla releases Firefox 4.0.1 with a security fix. Fedora 12 is shipping with 3.0.7, and though the bug is also present there, the fix in 4.0.1 does not apply because that part of the browser has been completely rewritten. Rebasing to 4.0.1 would be allowed since this is a security fix.
  • automake releases a new version that changes some warning conditions to errors. This would break the build process for existing packages, and would not be allowed.
  • AOL changes their instant messenger protocol in a way that requires an update to libpurple. The only upstream version of libpurple that supports the new protocol is an ABI break relative to the version in the current Fedora release. Rebasing would be allowed since this is an interoperability requirement.
  • Abiword releases a new version that adds compatibility with WordStar 4.0 documents. It also completely updates the user interface to use pie menus. This would be a feature enhancement with a major user experience change, and would not be allowed.
  • WebKit requires an update to solve a security problem. This requires updating Midori to a version with some minor menu layout changes. This would be a judgement call based on how intrusive the changes are (removing the File menu would be rude, but moving the plugin configuration menu item would be acceptable).
  • Firefox releases an update that only contains changes for other platforms. This update could be pushed to rawhide (just to keep up with the latest version), but should not be pushed to stable releases, as it does no good to our users and wastes resources to build, update, mirror and download to our users.
  • Terminal fails to build from source when tested in a mass rebuild. An updated package should be pushed to rawhide. Fixes for stable releases should be tested and even commited, but unless there is a problem with the previous existing build in the stable release, no update should be issued. This update would not change any user facing functions of the package.
  • KDE upstream releases a new major version, and at the same time stops supporting the older release that is in Fedora N and Fedora N-1. This release includes a large number of bugfixes, mixed with enhancements and security fixes. An exception for this type of update would need to consider: ability to backport major fixes/security issues, type and amount of bugs fixed, ability to not update other parts of fedora for this update (ie, avoid qt or other base library ABI changes), amount of testing and end user visible changes. An exception like this would be on a case by case bases based on all the above.

[edit] Problems or issues with Updates

In an effort to learn from any mistakes made, in the event of a update causing a widespread or serious problem for Fedora users, please file a FESCo trac ticket. FESCo will discuss and try and work to prevent the issue from happening again. A past record of such issues can be found at Updates Lessons.

FESCo will work with QA and others to prevent or mitigate the issue.

[edit] AutoQA

The AutoQA automated testing system runs two tests against all updates submitted to Bodhi: a dependency check (to ensure all dependencies of the package(s) can be fulfilled from the repositories) and an upgrade path check (to ensure the update does not break the upgrade path from release to release, i.e. that the update does not contain a package versioned higher than the newest version of the same package available in a later Fedora release). AutoQA adds comments to Bodhi with the results of these test runs. A failure of either test will cause Bodhi#Karma_Automatism for the update to be disabled (if it was enabled). If you submit an update that fails one of these tests, please check the result and fix the problem. If you are sure the failure is an error in the test rather than an error in your package, you may still manually push the update or re-enable karma automatism.

AutoQA is (as of 2014-08) being replaced with Taskotron. Initial Taskotron deployment will work similarly to AutoQA, but the set of tests and level of enforcement may grow in future. The QA:Package_Update_Acceptance_Test_Plan was written as the original plan for AutoQA update validation, and may still be seen as a framework for future work on Taskotron.