| |
@@ -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]
|
| |
mattdm
commented 2 years ago
This should resolve https://pagure.io/Fedora-Council/tickets/issue/384