From 01fa3769eea23369404974fcabaf1f24887b6529 Mon Sep 17 00:00:00 2001
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Date: Dec 13 2021 11:01:32 +0000
Subject: Merge #54 'Suggested new intro paragraph for Updates policy, plus supported changes'


zjs: Two minor issues found by @decathorpe in the review are fixed in the merge commit.

---

diff --git a/fesco/modules/ROOT/pages/Package_maintainer_responsibilities.adoc b/fesco/modules/ROOT/pages/Package_maintainer_responsibilities.adoc
index 1fb49b8..4f91d4c 100644
--- a/fesco/modules/ROOT/pages/Package_maintainer_responsibilities.adoc
+++ b/fesco/modules/ROOT/pages/Package_maintainer_responsibilities.adoc
@@ -58,9 +58,15 @@ It is recommended that maintainers:
 
 == Package updates
 
-The link:https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/[Package update policy] provides guidance for maintainers updating packages on an already-released branch.
+The link:https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/[Package update policy]
+provides guidance for maintainers who are updating packages
+in Rawhide,
+in "branched releases",
+and in the already-released "stable" branches.
+
 In summary, however, maintainers should bear in mind that:
 
+* Releases should go from less conservative (Rawhide) to more so (the oldest supported stable release).
 * Many Fedora users update automatically, so it is most important that an update doesn't cause a users' applications or system to stop working suddenly.
 * Fedora users who do not update automatically may review the descriptions attached to updates before choosing whether they should apply them.
 * Not all Fedora users have good Internet bandwidth available and may prefer a single update with multiple changes rather than many updates in a short period.
diff --git a/fesco/modules/ROOT/pages/Updates_Policy.adoc b/fesco/modules/ROOT/pages/Updates_Policy.adoc
index a12c496..e913c2b 100644
--- a/fesco/modules/ROOT/pages/Updates_Policy.adoc
+++ b/fesco/modules/ROOT/pages/Updates_Policy.adoc
@@ -2,6 +2,45 @@
 
 = Updates policy
 
+== Fedora's "First" foundation
+
+Fedora Linux is a fast-moving distribution by design.
+This is expressed in
+our xref:council::index.adoc#first[_First_] foundation:
+we provide the latest in stable and
+robust, useful, and powerful
+free software.
+
+Our community expects Fedora to integrate
+new software versions from various upstreams
+into our repositories quickly,
+but with minimal disruption and
+in a way that fits nicely with other packages.
+This balance is at the heart of being a package maintainer,
+and this document describes
+our policies for working together
+to create the best experience for everyone.
+
+We give individual package maintainers
+significant trust in how they manage and
+update their packages,
+within the
+xref:packaging-guidelines::index.adoc[Fedora Packaging Guidelines]
+and the policies here.
+But, please remember that this is a collective effort.
+We respect, appreciate, and celebrate the work
+each individual maintainer puts into their packages,
+and we _also_
+xref:Policy_for_encouraging_comaintainers_of_packages.adoc[encourage co-maintainership]
+and
+xref:Who_is_allowed_to_modify_which_packages.adoc[collaboration to improve packaging]
+across the entire Fedora collection.
+
+
+
+
+== About this policy
+
 Fedora has differing policies for each of its branches. This document describes for maintainers what
 sort of updates should be created in packages for each of the various branches of existing Fedora.
 In the event of questions or clarifications, please file a
diff --git a/fesco/modules/ROOT/pages/Who_is_allowed_to_modify_which_packages.adoc b/fesco/modules/ROOT/pages/Who_is_allowed_to_modify_which_packages.adoc
index 9b69d5d..b3288e5 100644
--- a/fesco/modules/ROOT/pages/Who_is_allowed_to_modify_which_packages.adoc
+++ b/fesco/modules/ROOT/pages/Who_is_allowed_to_modify_which_packages.adoc
@@ -62,6 +62,7 @@ That means:
   -- that includes:
 
 ** fix EVR problems, when they get mentioned in problem reports
+   (for example, a broken upgrade path)
 
 ** fix dependency issues (including those in the devel repo)
    -- the script sends problems to both the maintainer and the list
@@ -69,6 +70,9 @@ That means:
 ** participate in mass-rebuilds
    and fix xref:Fails_to_build_from_source_Fails_to_install.adoc[Fails to Build from Source] bugs
 
+* update to new versions of software as it becomes available upstream,
+  following the xref:Updates_Policy.adoc[updates policy]
+
 If the packager doesn't keep track of those items,
 then other experienced packagers are free to fix stuff for them.
 It's impossible to set a timeframe