Stable release updates vision

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Vision Statement)
(Some proposed changes)
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.}}
 
{{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.}}
  
Line 8: Line 7:
  
 
== 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 our target audience, which someone who:
+
  
 
# is voluntarily switching to Linux
 
# is voluntarily switching to Linux
Line 16: Line 14:
 
# 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.
  
Productivity is important to such a user, which means a shifting platform and visible behavioural changes are going to make them less productive.  Similarly, dealing with a large number of updates on a regular basis will be distracting.  Also, while the target user is likely to file a bug when something goes wrong, they are not expecting a stable release to utilize users as guinea pigs.
+
Productivity is important to such a user, which means a shifting platform and visible behavioral changes are going to make them less productive.  Similarly, dealing with a large number of updates on a regular basis will be distracting.  Also, while a user fitting these criteria is likely to file a bug when something goes wrong, the user does not automatically expect new issues to emerge in a stable release.
 
+
 
Another factor to keep in mind is Fedora's rapid development cycle.  A 6 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 our great 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 6 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 our great 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.
  
 
== Vision Statement ==
 
== Vision Statement ==
  
Taking the background and various factors above into account, the Board sees the Fedora updates streams as something that should fit into the following statement:
+
Taking the background and various factors above into account, the Board believes update streams should be managed with the following purposes:
  
"The update repositories for stable releases of the Fedora distribution should provide our users with a consistent and high quality stream of updates, primarily focused on resolving issues found within that version of the distribution."
+
* 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 concentrate on fixing bugs and security issues.
 +
* Close tracking of upstream should be done both through coordinating patch acceptance upstream, and by tracking the upstream version closely in Rawhide wherever possible.
 +
* More skilled and/or intrepid users should be encouraged to use Rawhide along with participating in testing of stable branches during the pre-release period.
 +
* The approach given to stable releases, pre-release branches, and Rawhide should have a graduated approach to updates.  For instance, given a proposed update that does more than fix a bug or security issue, it should not be easier to push that update to a stable release than to a pre-release branch or Rawhide.

Revision as of 19:10, 8 March 2010

Important.png
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.

Contents

Stable Release Update Vision

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 is contributing to confusion among package maintainers and end users alike. While everyone agrees that broken updates are detrimental to the Fedora distribution and should be avoided at all costs, there is no agreement on how to accomplish that nor is there agreement on what is an acceptable update. In light of this, the Fedora Board is issuing a stable release update vision statement to help guide the creation and implementation of a Fedora Updates policy.

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:

  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.

Productivity is important to such a user, which means a shifting platform and visible behavioral changes are going to make them less productive. Similarly, dealing with a large number of updates on a regular basis will be distracting. Also, while a user fitting these criteria is likely to file a bug when something goes wrong, the user does not automatically expect new issues to emerge in a stable release. Another factor to keep in mind is Fedora's rapid development cycle. A 6 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 our great 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.

Vision Statement

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

  • 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 concentrate on fixing bugs and security issues.
  • Close tracking of upstream should be done both through coordinating patch acceptance upstream, and by tracking the upstream version closely in Rawhide wherever possible.
  • More skilled and/or intrepid users should be encouraged to use Rawhide along with participating in testing of stable branches during the pre-release period.
  • The approach given to stable releases, pre-release branches, and Rawhide should have a graduated approach to updates. For instance, given a proposed update that does more than fix a bug or security issue, it should not be easier to push that update to a stable release than to a pre-release branch or Rawhide.