From Fedora Project Wiki
(Ready for Wrangler)
 
(7 intermediate revisions by 2 users not shown)
Line 14: Line 14:
 
* Name: [[User:Sgallagh| Stephen Gallagher]]
 
* Name: [[User:Sgallagh| Stephen Gallagher]]
 
* Name: [[User:langdon| Langdon White]]
 
* Name: [[User:langdon| Langdon White]]
<!-- In<!-- 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.
 
-->
 
 
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]]
 
 
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
 
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
 
* Email: sgallagh@fedoraproject.org
 
* Email: sgallagh@fedoraproject.org
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
+
* Email: langdon at fp dot o
 +
* Release notes ticket: [https://pagure.io/fedora-docs/release-notes/issue/73 #73]<!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
 
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
 
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
 
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
 
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
Line 63: Line 37:
 
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
 
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
 
-->
 
-->
* Tracker bug: <will be assigned by the Wrangler>
+
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1537253 #1537253]
  
 
== Detailed Description ==
 
== Detailed Description ==
Line 95: Line 69:
  
 
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.
 
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 ===
 
=== Release engineering ===
  
[https://pagure.io/releng/issue/7227 Ticket #7227] (a check of an impact with Release Engineering is needed)  
+
[https://pagure.io/releng/issue/7227 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.
 
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.
  
 
=== [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]] ===
 
=== [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]] ===
Line 178: Line 161:
 
To be written. Probably will be a condensed and updated version of [https://communityblog.fedoraproject.org/modularity-dead-long-live-modularity/ the Long Live Modularity blog post], focused on user experience with links to contributor/developer information.
 
To be written. Probably will be a condensed and updated version of [https://communityblog.fedoraproject.org/modularity-dead-long-live-modularity/ the Long Live Modularity blog post], focused on user experience with links to contributor/developer information.
  
[[Category:ChangeReadyForWrangler]]
+
[[Category:ChangeAcceptedF28]]
 
<!-- 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 -->

Latest revision as of 14:35, 2 March 2018

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

Current status

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). 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:

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.