Stable release updates vision

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Make this part easier to read)
m (Implementation: wikilink)
 
(16 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{admon/important|DRAFT|This is only a draft at this time.  The content needs to be discussed, refined, and agreed upon by the Fedora Board before an action is taken on the content within.}}
+
__TOC__
 
+
= Stable Release Update Vision =
+
 
+
 
== Background ==
 
== Background ==
Recent discussions on various Fedora mailing lists have shown that we currently have a wide variety of positions on what Fedora's update strategy should look like.  These range from a ''rolling'' release, to a ''locked down security-only update'' solution.  The lack of clarity on this issue contributes to confusion among package maintainers and end users alike. 
 
  
Most people agree that broken updates are detrimental to the Fedora distribution and should be avoided at all costs.
+
Discussions on March 2010 in various Fedora mailing lists have shown that we currently have a wide variety of positions on what Fedora's update strategy should look like.  These range from a ''rolling'' release, to a ''locked down security-only update'' solution.  The lack of clarity on this issue contributes to confusion among package maintainers and end users alike. 
 +
 
 +
Most people agree that broken updates are detrimental to the Fedora distribution and should be avoided.
  
 
Fewer people agree on:
 
Fewer people agree on:
 
* How many updates are acceptable for a stable release and how to measure them
 
* How many updates are acceptable for a stable release and how to measure them
* What constitutes an acceptable update to a stable release.
+
* What constitutes an acceptable update to a stable release.
 +
* At what cost should broken updates be avoided, trading off occasional broken updates for delivery speed for new software and maintainer workflow simplicity.
  
For these reasons, the Fedora Board is issuing a stable release update vision statement to help guide the creation and implementation of a Fedora Updates policy.
+
For these reasons, the Fedora Board is issuing a stable release update vision statement to help guide the creation and implementation of a Fedora Updates policy.  This policy is not meant to govern the introduction of new packages.
  
 
By creating this statement it is the Board's belief that:
 
By creating this statement it is the Board's belief that:
 
* End-user satisfaction with our distribution will increase
 
* End-user satisfaction with our distribution will increase
* Developers and end-users will have a have a more solid stable release experience
+
* Developers and end-users will have a more solid stable release experience
 
* End-users and developers will have more time to focus on other areas in Fedora
 
* End-users and developers will have more time to focus on other areas in Fedora
  
 
== Factors ==
 
== Factors ==
When creating an updates overview, there are some factors that need to be taken into account.  The first, and foremost, is keeping in mind the broad criteria the Board set out for the entire Fedora distribution, which describe someone who:
+
When creating an updates overview, there are some factors that need to be taken into account.  The first, and foremost, is keeping in mind [https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00350.html the broad criteria] the Board set out for the target audience of the entire Fedora distribution, which describe someone who:
  
 
# is voluntarily switching to Linux
 
# is voluntarily switching to Linux
Line 27: Line 26:
 
# wants to use Fedora for general productivity, either using desktop applications or a Web browser.
 
# wants to use Fedora for general productivity, either using desktop applications or a Web browser.
  
A shifting platform and visible behavioral changes will affect the user's productivity becuase the user must take time away from the desired tasks to discover what has changed, adjust the way they perform supporting tasks, and refocus on their original objectives.  Because productivity is postulated as important to this user, this outcome is undesirable.  Similarly, dealing with a large number of updates on a regular basis is distracting from the user's desired productivity tasks.  Also, while a user fitting these criteria is likely to file a bug when something goes wrong, the user does not therefore automatically expect new issues to emerge in a stable release as a result of consuming updates offered authoritatively.  When such issues do emerge, the user's confidence in the platform is undermined.
+
A shifting platform and visible behavioral changes will affect the user's productivity because the user must take time away from the desired tasks to discover what has changed, adjust the way they perform supporting tasks, and refocus on their original objectives.  Because productivity is postulated as important to this user, this outcome is undesirable.  Similarly, dealing with a large number of updates on a regular basis is distracting from the user's desired productivity tasks.
 +
 
 +
Updates offered by our built-in tools under the auspices of the Fedora Project are seen as authoritative by usersWhile a user fitting these criteria is likely to file a bug when something goes wrong, the user does not therefore automatically expect new issues to emerge in a stable release as a result of consuming those updates.  When such issues do emerge, the user's confidence in the platform is undermined.
  
 
Another factor to keep in mind is Fedora's rapid development cycle.  A six month development cycle for a release allows Fedora to integrate the latest and greatest releases from upstream projects into the 'rawhide' distribution and have that body of work available to the user base in a relatively short amount of time.  Ideally, this rapid paced release cycle allows both developers and users the chance to focus on a coherent, consistent, and well functioning set of software content per release.
 
Another factor to keep in mind is Fedora's rapid development cycle.  A six month development cycle for a release allows Fedora to integrate the latest and greatest releases from upstream projects into the 'rawhide' distribution and have that body of work available to the user base in a relatively short amount of time.  Ideally, this rapid paced release cycle allows both developers and users the chance to focus on a coherent, consistent, and well functioning set of software content per release.
Line 38: Line 39:
 
* Stable releases should provide a consistent user experience throughout the lifecycle, and only fix bugs and security issues.
 
* Stable releases should provide a consistent user experience throughout the lifecycle, and only fix bugs and security issues.
 
* Stable releases should not be used for tracking upstream version closely when this is likely to change the user experience beyond fixing bugs and security issues.
 
* Stable releases should not be used for tracking upstream version closely when this is likely to change the user experience beyond fixing bugs and security issues.
* Close tracking of upstream should be done both by moving patches upstream, and by tracking the upstream version closely in ''Rawhide'' repo wherever possible.
+
* Close tracking of upstream should be done in the Rawhide repo wherever possible, and we should strive to move our patches upstream.
 
* More skilled and/or intrepid users are encouraged to use [[Rawhide | ''Rawhide'']] along with participating in testing of stable branches during the development and pre-release period.
 
* More skilled and/or intrepid users are encouraged to use [[Rawhide | ''Rawhide'']] along with participating in testing of stable branches during the development and pre-release period.
* Stable releases, pre-release branches, and Rawhide should have a graduated approach to ease of updating.  For example, if a proposed update does more than fix a bug or security issue, it should be harder to push that update to a stable release than to a pre-release branch or Rawhide.
+
* Stable releases, pre-release branches, and Rawhide have a graduated approach to what types of updates are expected.  For example, a pre-release branch should accept some updates which a stable release would not, and rawhide would accept updates that are not appropriate for either a stable release or a pre-release.
 
* Project members should be able to transparently measure or monitor a new updates process to objectively measure its effectiveness, and determine whether the updates process is achieving the aforementioned vision statements.
 
* Project members should be able to transparently measure or monitor a new updates process to objectively measure its effectiveness, and determine whether the updates process is achieving the aforementioned vision statements.
 +
 +
== Implementation ==
 +
 +
Following the Fedora Board vision statement, the following policy was approved and in effect from October 2010
 +
 +
[[Updates Policy]]
 +
 +
[[Category:Board]]

Latest revision as of 20:59, 17 January 2014

Contents

[edit] Background

Discussions on March 2010 in various Fedora mailing lists have shown that we currently have a wide variety of positions on what Fedora's update strategy should look like. These range from a rolling release, to a locked down security-only update solution. The lack of clarity on this issue contributes to confusion among package maintainers and end users alike.

Most people agree that broken updates are detrimental to the Fedora distribution and should be avoided.

Fewer people agree on:

  • How many updates are acceptable for a stable release and how to measure them
  • What constitutes an acceptable update to a stable release.
  • At what cost should broken updates be avoided, trading off occasional broken updates for delivery speed for new software and maintainer workflow simplicity.

For these reasons, the Fedora Board is issuing a stable release update vision statement to help guide the creation and implementation of a Fedora Updates policy. This policy is not meant to govern the introduction of new packages.

By creating this statement it is the Board's belief that:

  • End-user satisfaction with our distribution will increase
  • Developers and end-users will have a more solid stable release experience
  • End-users and developers will have more time to focus on other areas in Fedora

[edit] Factors

When creating an updates overview, there are some factors that need to be taken into account. The first, and foremost, is keeping in mind the broad criteria the Board set out for the target audience of the entire Fedora distribution, which describe someone who:

  1. is voluntarily switching to Linux
  2. is familiar with computers but is not necessarily a hacker or developer
  3. is likely to collaborate in some fashion when something's wrong with Fedora, and
  4. wants to use Fedora for general productivity, either using desktop applications or a Web browser.

A shifting platform and visible behavioral changes will affect the user's productivity because the user must take time away from the desired tasks to discover what has changed, adjust the way they perform supporting tasks, and refocus on their original objectives. Because productivity is postulated as important to this user, this outcome is undesirable. Similarly, dealing with a large number of updates on a regular basis is distracting from the user's desired productivity tasks.

Updates offered by our built-in tools under the auspices of the Fedora Project are seen as authoritative by users. While a user fitting these criteria is likely to file a bug when something goes wrong, the user does not therefore automatically expect new issues to emerge in a stable release as a result of consuming those updates. When such issues do emerge, the user's confidence in the platform is undermined.

Another factor to keep in mind is Fedora's rapid development cycle. A six month development cycle for a release allows Fedora to integrate the latest and greatest releases from upstream projects into the 'rawhide' distribution and have that body of work available to the user base in a relatively short amount of time. Ideally, this rapid paced release cycle allows both developers and users the chance to focus on a coherent, consistent, and well functioning set of software content per release.

[edit] Vision Statement

Taking the background and various factors above into account, the Board believes update streams should be managed with the following purposes in mind:

  • The update repositories for stable releases of the Fedora distribution should provide our users with a consistent and high quality stream of updates.
  • Stable releases should provide a consistent user experience throughout the lifecycle, and only fix bugs and security issues.
  • Stable releases should not be used for tracking upstream version closely when this is likely to change the user experience beyond fixing bugs and security issues.
  • Close tracking of upstream should be done in the Rawhide repo wherever possible, and we should strive to move our patches upstream.
  • More skilled and/or intrepid users are encouraged to use Rawhide along with participating in testing of stable branches during the development and pre-release period.
  • Stable releases, pre-release branches, and Rawhide have a graduated approach to what types of updates are expected. For example, a pre-release branch should accept some updates which a stable release would not, and rawhide would accept updates that are not appropriate for either a stable release or a pre-release.
  • Project members should be able to transparently measure or monitor a new updates process to objectively measure its effectiveness, and determine whether the updates process is achieving the aforementioned vision statements.

[edit] Implementation

Following the Fedora Board vision statement, the following policy was approved and in effect from October 2010

Updates Policy