From Fedora Project Wiki
(Initial pass)
 
(Clean-ups)
Line 1: Line 1:
<!-- Self Contained or System Wide Change Proposal?
<!-- Self Contained or System Wide Change Proposal?
Use this guide to determine to which category your proposed change belongs to.
Self Contained Changes are:
* changes to isolated/leaf package without the impact on other packages/rest of the distribution
* limited scope changes without the impact on other packages/rest of the distribution
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG
System Wide Changes are:
* changes that does not fit Self Contained Changes category touching
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)
* changing system defaults
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). 
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.
-->
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
= Change Proposal Name <!-- The name of your change proposal --> =
Add-On Modularity
== Summary ==
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. -->
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.
== Owner ==
<!--
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages.
This should link to your home wiki page so we know who you are.
-->
* Name: [[User:Sgallagh| Stephen Gallagher]]
<!-- In<!-- Self Contained or System Wide Change Proposal?
Use this guide to determine to which category your proposed change belongs to.
Use this guide to determine to which category your proposed change belongs to.


Line 74: Line 109:
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?-->
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?-->


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).
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). Fsor 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 ==
== Scope ==
Line 87: Line 122:
Developers that 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 that 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.


* Release engineering: [https://pagure.io/releng/issues #7227] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
* Release engineering: [https://pagure.io/releng/issues #7227] (a check of an impact with Release Engineering is needed)  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.
 
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 -->
This Change will require considerable interaction with Release Engineering and the Factory 2.0 teams.




** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: All
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: All
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->
 
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).
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).


Line 158: Line 193:
* https://fedoraproject.org/wiki/Module:Guidelines
* https://fedoraproject.org/wiki/Module:Guidelines


== Release Notes {{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.<br/> '''Copy the source to a ''new page'' before making changes!  DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}==
== Release Notes ==
 
{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.<br/> '''Copy the source to a ''new page'' before making changes!  DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}==
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this change, indicate them here.  A link to upstream documentation will often satisfy this {{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.<br/> '''Copy the source to a ''new page'' before making changes!  DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release.  
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this change, indicate them here.  A link to upstream documentation will often satisfy this {{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.<br/> '''Copy the source to a ''new page'' before making changes!  DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release.  

Revision as of 15:47, 2 January 2018


Change Proposal Name

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.

Owner


Change Proposal Name

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.

Owner

Current status

  • Targeted release: Fedora 28
  • Last updated: 2018-01-02
  • Tracker bug: <will be assigned by the Wrangler>

Detailed Description

Fedora 28 will extend the set of available repositories to include

  • modular
  • modular-updates
  • modular-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). Fsor 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 that 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.

  • Release engineering: #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.


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:

Release Notes

Important.png
Comments and Explanations
The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.

==

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