From Fedora Project Wiki

(move things up a level)
Line 5: Line 5:
Fedora has differing policies for each of it's branches. This document describes for maintainers what sort of updates should be created in packages for each of the various branches of fedora that exist. 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).  
Fedora has differing policies for each of it's branches. This document describes for maintainers what sort of updates should be created in packages for each of the various branches of fedora that exist. 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).  


== Rawhide / devel / master ==
= Rawhide / devel / master =


Rawhide is the always rolling development release. Package updates built for rawhide are composed every day and pushed out to all rawhide consumers. There is no updates or updates-testing for rawhide. The Bodhi updates system is not used.
Rawhide is the always rolling development release. Package updates built for rawhide are composed every day and pushed out to all rawhide consumers. There is no updates or updates-testing for rawhide. The Bodhi updates system is not used.
Line 15: Line 15:
* Feel free to push out the newest version of packages as long as they don't 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 don't 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.


== 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 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.
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.


=== 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 stablize  
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 stablize  
Line 32: Line 32:
* All non critical path updates MUST spend at least 3 days in updates-testing before going to stable.  
* All non critical path updates MUST spend at least 3 days in updates-testing before going to stable.  


=== Beta to Release ===
== Beta to 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 stablized and prepped for release. Major changes should be avoided during this period. During this time maintainers MUST:  
This is the time between the Beta release and the final release as stable of the branched OS. The branched OS should now be stablized and prepped for release. Major changes should be avoided during this period. During this time maintainers MUST:  
Line 41: Line 41:
* All non critical path updates MUST spend at least 7 days in updates-testing before going to stable.  
* All non critical path updates MUST spend at least 7 days in updates-testing before going to stable.  


=== Pre release ===
== Pre release ==


During this time the release is being composed and all non blocker changes should be avoided. As release nears, a updates repo will become available, so updates will be in that after release instead of being added into the core OS.  
During this time the release is being composed and all non blocker changes should be avoided. As release nears, a updates repo will become available, so updates will be in that after release instead of being added into the core OS.  
Line 51: Line 51:
* Other updates may go to updates repo as soon as it's available.  
* Other updates may go to updates repo as soon as it's available.  


== Stable Releases ==
= Stable Releases =


=== Philosophy ===
== 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.
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.
Line 70: Line 70:
* All non critical path updates MUST spend at least 7 days in updates-testing before going to stable.  
* All non critical path updates MUST spend at least 7 days in updates-testing before going to stable.  


=== 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.  
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.  


==== Security fixes ====
=== 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 judgement of FESCO and the packager.
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 judgement of FESCO and the packager.


==== Interoperability ====
=== 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.
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.
Line 84: Line 84:
Examples of this type of package: libopenraw, libimobiledevice, calibre, pilot-link
Examples of this type of package: libopenraw, libimobiledevice, calibre, pilot-link


==== Database packages ====
=== 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.
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.
Line 90: Line 90:
Examples of this type of package: spamassassin, clamav
Examples of this type of package: spamassassin, clamav


==== Examples ====
=== 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.
* 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.

Revision as of 17:59, 20 September 2010

Warning.png
HI I AM A DRAFT
Don't take me seriously yet, I'm still under review.

Introduction

Fedora has differing policies for each of it's branches. This document describes for maintainers what sort of updates should be created in packages for each of the various branches of fedora that exist. 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).

Rawhide / devel / master

Rawhide is the always rolling development release. Package updates built for rawhide are composed every day and pushed out to all rawhide consumers. There is no updates or updates-testing for rawhide. The Bodhi updates system is not used. For updates to rawhide packages, Maintainers SHOULD:

  • Try not to push a clearly broken build.
  • Notify maintainers that depend on their package to rebuild when there are abi/api changes that require rebuilds in other packages.
  • Use a seperate buildsystem tag when dealing with mass builds of many packages, so they can land at the same time.
  • Feel free to push out the newest version of packages as long as they don't 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.

Branched release

A 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.

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 stablize the major versions of software that will be shipped with the final release of the OS. Major updates would be tolerated, but breaking things for early testers should be avoided if possible. Packages for Features should be landing and getting major testing.

During this time Maintainers MUST:

  • Push all updates first to updates-testing.
  • All critical path updates MUST get one +1 karma from a proventester before being moved to stable.
  • All non critical path updates MUST spend at least 3 days in updates-testing before going to stable.

Beta to 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 stablized and prepped for release. Major changes should be avoided during this period. During this time maintainers MUST:

  • Avoid Major version updates, ABI breakage or API changes if at all possible.
  • Push updates first to updates-testing.
  • All critical path updates MUST get one +1 karma from a proventester and +1 karma from another user before going stable.
  • All non critical path updates MUST spend at least 7 days in updates-testing before going to stable.

Pre release

During this time the release is being composed and all non blocker changes should be avoided. As release nears, a updates repo will become available, so updates will be in that after release instead of being added into the core OS.

  • All updates pulled into the release MUST fix a blocker.
  • Push updates first to updates-testing.
  • All critical path updates MUST get one +1 karma from a proventester and +1 karma from another user before going stable.
  • All non critical path updates MUST spend at least 7 days in updates-testing before going to stable.
  • Other updates may go to updates repo as soon as it's available.

Stable Releases

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.

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.

  • Avoid Major version updates, ABI breakage or API changes if at all possible.
  • Avoid changing the user experence if at all possible.
  • Avoid updates that are trivial or don't affect any Fedora users.
  • Push updates first to updates-testing.
  • All critical path updates MUST get one +1 karma from a proventester and +1 karma from another user before going stable.
  • All non critical path updates MUST spend at least 7 days in updates-testing before going to stable.

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.

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 judgement of FESCO and the packager.

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: libopenraw, libimobiledevice, calibre, pilot-link

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: spamassassin, clamav

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).

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: https://fedoraproject.org/wiki/Updates_Lessons

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

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.