#148 Create "historical docs" section and add the boards' Stable Updates Vision
Merged a month ago by bcotton. Opened 3 months ago by mattdm.
Fedora-Council/ mattdm/council-docs historical_docs  into  main

@@ -20,4 +20,7 @@ 

  *** xref:procedures/survey/overview.adoc[Survey Overview]

  *** xref:procedures/survey/how-to.adoc[How to run a Survey]

  *** xref:procedures/survey/questions.adoc[Survey Questions]

+ * Historical Documents

+ ** xref:historical/historical_note.adoc[About this section]

+ ** xref:historical/board_stable_updates_vision.adoc[Stable Updates Vision]

  * xref:history.adoc[Council and Board Historical Membership]

@@ -0,0 +1,34 @@ 

+ ////


+ This message needs to be included in any document in the "historical"

+ section, so that people are not mislead.


+ Add the following line verbatim to the top of any such document:


+ include::{partialsdir}/historical_warning.adoc[]


+ Please also include a [NOTE] adminition;

+ something like the following example:


+ [NOTE]

+ ====

+ This is a Fedora Board policy,

+ adopted in 2010.

+ It shows how

+ _something happened or whatever_

+ but is now irrelevant because

+ _something changed_.

+ ====



+ ////



+ ====

+ This page preserves a document

+ from Fedora's past.

+ It may not

+ (and probably _does not_)

+ reflect current policy

+ or Fedora Project practices.

+ ====

@@ -0,0 +1,126 @@ 

+ include::{partialsdir}/historical_warning.adoc[]



+ [NOTE]

+ ====

+ The "Stable Updates Vision"

+ was adopted by the Fedora Board

+ in March 2010,

+ and is referenced in the _current_

+ Fedora Engineering Steering Committee

+ https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/[updates policy].

+ While some of the background factors

+ have changed since then,

+ the fundamentals which informed the FESCo policy

+ are still relevant.

+ ====


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


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

+ 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 familiar with computers but is not necessarily a hacker or

+ developer

+ . is likely to collaborate in some fashion when something's wrong with

+ Fedora, and

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


+ [[vision_statement]]

+ == 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 link:Rawhide[

+ _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.


+ == Implementation


+ Following the Fedora Board vision statement, the following policy was

+ approved and in effect from October 2010:


+ https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/[Updates Policy]

@@ -0,0 +1,27 @@ 

+ = Fedora Governance Historical Documents


+ Fedora has a long history,

+ and things have changed along the way.

+ Sometimes,

+ there are policy or procedure documents

+ that have significance for remembering

+ why things are the way they are

+ and how we got here.


+ This section is for those,

+ so they can be found in one plcae

+ rather than scattered everywhere,

+ and so they aren't accidentally lost forever

+ in some future infrastructure transition.


+ We don't want to keep _everything_,

+ and even of text worth preserving,

+ this isn't necessarily the place.

+ But if you find something that

+ you think is relevant to Fedora's

+ guiding policies,

+ overall governance,

+ or similar,

+ please submit as a pull request

+ to the https://pagure.io/Fedora-Council/council-docs[Council Docs].

+ Thank you! 

\ No newline at end of file