From 61a36765679f751195a8066e87f0ae941e753567 Mon Sep 17 00:00:00 2001 From: Matthew Miller Date: Oct 26 2022 14:29:26 +0000 Subject: [PATCH 1/3] Add "historical docs" section, and explanatory note --- diff --git a/council/modules/ROOT/nav.adoc b/council/modules/ROOT/nav.adoc index d5cebd9..6db93c9 100644 --- a/council/modules/ROOT/nav.adoc +++ b/council/modules/ROOT/nav.adoc @@ -20,4 +20,6 @@ *** 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:history.adoc[Council and Board Historical Membership] diff --git a/council/modules/ROOT/pages/historical/historical_note.adoc b/council/modules/ROOT/pages/historical/historical_note.adoc new file mode 100644 index 0000000..aa00c89 --- /dev/null +++ b/council/modules/ROOT/pages/historical/historical_note.adoc @@ -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 From 5d9b01febd2a8f601880e7bf9be3d7591f304e4f Mon Sep 17 00:00:00 2001 From: Matthew Miller Date: Oct 26 2022 14:29:26 +0000 Subject: [PATCH 2/3] add note for future archivists --- diff --git a/council/modules/ROOT/pages/_partials/historical_warning.adoc b/council/modules/ROOT/pages/_partials/historical_warning.adoc new file mode 100644 index 0000000..beb28a7 --- /dev/null +++ b/council/modules/ROOT/pages/_partials/historical_warning.adoc @@ -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_. +==== + + +//// + +[CAUTION] +==== +This page preserves a document +from Fedora's past. +It may not +(and probably _does not_) +reflect current policy +or Fedora Project practices. +==== From 68ffe5c5ed749133e7e5dca91f009728910ec806 Mon Sep 17 00:00:00 2001 From: Matthew Miller Date: Oct 26 2022 14:29:26 +0000 Subject: [PATCH 3/3] add the Stable Updates Vision doc --- diff --git a/council/modules/ROOT/nav.adoc b/council/modules/ROOT/nav.adoc index 6db93c9..18e5044 100644 --- a/council/modules/ROOT/nav.adoc +++ b/council/modules/ROOT/nav.adoc @@ -22,4 +22,5 @@ *** 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] diff --git a/council/modules/ROOT/pages/historical/board_stable_updates_vision.adoc b/council/modules/ROOT/pages/historical/board_stable_updates_vision.adoc new file mode 100644 index 0000000..42c2efb --- /dev/null +++ b/council/modules/ROOT/pages/historical/board_stable_updates_vision.adoc @@ -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]