Add-On Modularity
Summary
Beginning in Fedora 28, Fedora will provide a new set of repositories for software and updates with alternative versions from those shipped in the default release.
Please see Modularity is Dead, Long Live Modularity! for an in-depth description of the plan.
Owner
- Name: Stephen Gallagher
- Name: Langdon White
- Email: sgallagh@fedoraproject.org
- Email: langdon at fp dot o
- Release notes ticket: #73
Current status
Detailed Description
Fedora 28 will extend the set of available repositories to include
modularmodular-updatesmodular-updates-testing
These repositories will provide access to Fedora Modules, a set of alternative package streams that can replace the versions shipped by default in Fedora.
Benefit to Fedora
Modularity provides users the opportunity to solve the "too fast/too slow" problem in Fedora. For users that need to maintain an older piece of software, they can "lock" themselves on a particular framework between Fedora releases (for as long as that version is supported/supportable). For users that need to be using a newer version of software than what was shipped in the release, an updated stream can be made available without forcing all users of Fedora to migrate to it (if there are compatibility concerns).
Scope
Proposal owners
The feature owners need to provide a set of reference modules and module-streams that can be composed into the new repository. The set of available packages can and should increase over time as other packagers start taking advantage of it.
Other developers
Developers who wish to offer multiple streams of software in Fedora will need to update their packaging process to take advantage of the new dist-git branching features to allow them to build the same version across multiple releases of Fedora.
Developers who are not interested in doing this at this time will not need to make any changes. When co-maintainers of a packages have different interests, they will need to coordinate.
MirrorManager will need an update to know about the new modular repos.
Release engineering
Ticket #7227 (a check of an impact with Release Engineering is needed)
This Change will require considerable interaction with Release Engineering and the Factory 2.0 teams.
- New Modular Repositories (one under release, one under updates, one under updates-testing)
- Stream Expansion from Factory 2.0
- Automatic creation of basic modules https://pagure.io/modularity/issue/97
- Default streams tagged into base
Work will be tracked in Taiga — links to specific items to come.
List of deliverables
Affects several release blocking deliverables.
There will be an additional fedora-repos-modular package that will be installed by default on some Editions/Spins (each WG or SIG will need to make their own decision on whether to ship modules enabled by default).
Policies and guidelines
Yes
Some guidelines are already available at https://fedoraproject.org/wiki/Module:Guidelines, however we have plans in place to vastly simplify the process, which should make packagers' lives much easier.
Trademark approval
N/A (not needed for this Change)
Upgrade/compatibility impact
The new Modularity approach will need to be tested to ensure that upgrades work properly from Fedora 27 to Fedora 28 with all modules in their default streams. For Fedora 27->28, modules will become available only after upgrade. Beginning with Fedora 28->29, we will need to also test and support upgrades that remain on a selected module stream, but that will be a Fedora 29 Change Proposal.
How To Test
Testing of this feature will require verifying that each Edition provides (or not) the new modular repositories and can successfully install software with or without those new repositories being enabled. They will also need to test that enabling and installing a non-default module stream works when the modular repositories are enabled.
User Experience
This will be a highly visible change, as it will offer users a much wider range of versions of their software from which to choose (with the defaults remaining as they have in traditional Fedora).
Dependencies
There are significant dependencies on the release engineering and Factory 2.0 teams to make this work.
Contingency Plan
- Contingency mechanism: The various release artifacts will ship without having the modular repositories enabled. Release Engineering will probably want to suppress any existing repository content from the mirrors to save bandwidth.
- Contingency deadline: Beta Freeze
- Blocks release? No
- Blocks product? No
Documentation
This will be updated as we go. For now:
- https://communityblog.fedoraproject.org/modularity-dead-long-live-modularity/
- https://fedoraproject.org/wiki/Module:Guidelines
Release Notes
To be written. Probably will be a condensed and updated version of the Long Live Modularity blog post, focused on user experience with links to contributor/developer information.