From Fedora Project Wiki
(releng, ChangeReadyForWrangler)
(add release note ticket)
 
(13 intermediate revisions by 4 users not shown)
Line 4: Line 4:
= Retire Modularity <!-- The name of your change proposal --> =
= Retire Modularity <!-- The name of your change proposal --> =


{{Change_Proposal_Banner}}


== Summary ==
== Summary ==
Line 26: Line 25:


== Current status ==
== Current status ==
[[Category:ChangeReadyForWrangler]]
[[Category:ChangeAcceptedF39]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
Line 44: Line 43:
ON_QA -> change is fully code complete
ON_QA -> change is fully code complete
-->
-->
* [<will be assigned by the Wrangler> devel thread]
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ECODXGUX6F2JLFOMW3NV6BTZEZR6LA2I/ devel thread]
* FESCo issue: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/3027 #3027]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2226798 #2226798]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/1016 #1016]


== Detailed Description ==
== Detailed Description ==
Line 74: Line 73:
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. -->
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. -->


TBD
=== What will be offered as a replacement ===


We have been asked internally at Red Hat, what will be offered to users of Fedora Linux if we retire modularity.
While we encourage anyone to share ideas they might have on the topic, we intentionally offer no ''new'' alternative to modularity as part of this change proposal. Replacing the retired modularity with something else is intentionally out of scope of this proposal.


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 113: Line 114:
** Work with releng to disable composing and mirroring of modular repos for f39+
** Work with releng to disable composing and mirroring of modular repos for f39+
** Work with Bodhi admins to disable F39+ Modular updates
** Work with Bodhi admins to disable F39+ Modular updates
** Submit changes to fedora-repos package to remove and obsolete the modular subpackages
** Submit changes to fedora-repos package to remove and obsolete the modular subpackages: https://src.fedoraproject.org/rpms/fedora-repos/pull-request/121
** Remove fedora-repos-modular from comps: https://pagure.io/fedora-comps/pull-request/857
** (once f38 is EOL) Work with infra to sunset MBS
** (once f38 is EOL) Work with infra to sunset MBS
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
Line 129: Line 131:
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->


* Policies and guidelines: N/A (not needed for this Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: https://pagure.io/fedora-docs/modularity/pull-request/107 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. Please submit a pull request with the proposed changes before submitting your Change proposal. -->
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. Please submit a pull request with the proposed changes before submitting your Change proposal. -->


Latest revision as of 23:40, 28 September 2023


Retire Modularity

Summary

Fedora will discontinue building modules for Fedora Linux 39 and further in the Fedora infrastructure and shipping modular content to users. The fedora-repos-modular and fedora-repos-rawhide-modular packages will be retired and obsoleted. The modular repositories will no longer be composed. Once Fedora Linux 38 reaches the end of life, Fedora's Module Build Service will be terminated. Whether or not dnf(5) would still support modularity from 3rd party repository is out of the scope of this proposal.

Owner


Current status

Detailed Description

Motivation

There are very few modules left in Fedora, nobody is developing modularity anymore and there is an everlasting infrastructure problem with building modules. Similarly to retiring a package that has no maintainers, we are retiring Modularity from Fedora, because it has no maintainers. The latest noticeable activity in pagure.io/modularity was 3+ years ago.

What will happen

  1. After Fedora Linux 38 branches from Rawhide, we will disable building modules for Rawhide and future Fedora Linux 39 and later.
  2. We will work with Release Engineering to disable composing of modular repositories, F39 Modular updates in Bodhi etc.
  3. The fedora-repos-modular and fedora-repos-rawhide-modular subpackages of fedora-repos will be removed and obsoleted by fedora-repos and fedora-repos-rawhide.
  4. Once Fedora Linux 38 reaches end of life, we will retire the Fedora instance of Module Build Service.

What might or might not happen

Whether or not the package manager in Fedora Linux (dnf and/or dnf5) will support modular repositories created by 3rd parties is not decided in this change proposal. It is up to the dnf maintainers to make this decision and we intentionally want to make the scope of this proposal as limited as possible.

For maintainers of modules

Please retire your modules appropriately, so users are migrated to suitable non-modular content. If you wish to continue shipping multiple different versions or editions of your packages, please follow Multiple packages with the same base name, as was a recommendation of the policy for many years.

Feedback

What will be offered as a replacement

We have been asked internally at Red Hat, what will be offered to users of Fedora Linux if we retire modularity. While we encourage anyone to share ideas they might have on the topic, we intentionally offer no new alternative to modularity as part of this change proposal. Replacing the retired modularity with something else is intentionally out of scope of this proposal.

Benefit to Fedora

Packager and Infra/Releng resources will not be wasted on Modularity. Instead, we can focus on delivering quality content to our users without it.

Scope

  • Other developers:
    • Modular packagers:
      • Retire your modules
      • Ideally package the content as nonmodular
  • Release engineering: #11480
    • Disable modular builds in f39+
    • Disable composing and mirroring of modular repos for f39+
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Community Initiatives:

Upgrade/compatibility impact

An RPM scriptlet fedora-release might be necessary to deactivate all Fedora-provided modular streams when upgrading to Fedora Linux 39 and 40. This will only happen if all other means of properly EOLing the modules still block upgrades.

How To Test

Has this landed?

  1. Check if fedora-repos-modular and fedora-repos-rawhide-modular are missing from the repository and Obsoleted.
  2. Check if the modular repositories are missing from download.fedoraproject.org and mirrormanager.

Does it work?

  1. Check if upgrading from Fedora Linux 37/38 to 39/40 with enabled modular streams (from the Fedora repos) is still possible.

User Experience

Users of Fedora Linux 39+ will no longer have access to the Fedora modular repos. They can still install non-modular packages instead.

Dependencies

Contingency Plan

  • Contingency mechanism: Revert the changes
  • Contingency deadline: Beta Freeze
  • Blocks release? No

Documentation

Ideally, all references to Fedora-provided modular streams should be removed from docs.fedoraproject.org, except for docs.fedoraproject.org/en-US/modularity which should be clearly marked as obsolete/archived.

Release Notes

Users of Fedora Linux 39+ will no longer have access to the Fedora modular repos. They can still install non-modular packages instead.

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/RetireModularity&oldid=690552"