From Fedora Project Wiki
(Created page with "= Objective: Modularity Improvements (2020) = == Summary == Plans for Fedora 33 and 34 are to improve the existing implementation of Modularity. We may look into alternatives...")
 
No edit summary
Line 27: Line 27:
** Improve documentation and guidelines for users and packagers
** Improve documentation and guidelines for users and packagers
** Implement low-level tools for building modules locally and managing (editing, creating) modulemd data locally
** Implement low-level tools for building modules locally and managing (editing, creating) modulemd data locally
** Implement the [[Changes/Module_Obsoletes_and_EOL|Module Obsoletes and EOL]] Change to fix system upgrades
** Implement the [[Changes/Module_Obsoletes_and_EOL|Module Obsoletes and EOL]] Change to fix system upgrades (we missed the deadline, but we still want to deliver the code in F33 and modify the Change to start using it in F34)
* Fedora 34
* Fedora 34
** Use the [[Changes/Module_Obsoletes_and_EOL|Module Obsoletes and EOL]] Change to fix system upgrades
** Implement the [[Changes/Module_Context_Upgrade_Paths|Module Context Upgrade Paths]] Change
** Implement the [[Changes/Module_Context_Upgrade_Paths|Module Context Upgrade Paths]] Change
** Implement module stream switching
** Implement module stream switching

Revision as of 07:26, 26 August 2020

Objective: Modularity Improvements (2020)

Summary

Plans for Fedora 33 and 34 are to improve the existing implementation of Modularity. We may look into alternatives or bigger design changes in Fedora 35 and later.

Background

The current implementation of Modularity landed in Fedora 29. There were identified gaps that impact user experience. Even though there have been several fixes and improvements, there is still a lot to do. A new team started to own the Modularity project at Red Hat in February 2020. The team has posted a survey and the feedback identified many gaps, especially from the packagers’ point of view.

Goals

According to the survey, the team identified priorities for the next 12-18 months:

  1. Maintain Modularity to be available for any projects under the Fedora Project umbrella (Fedora packages, SIGs, Spins, etc., including EPEL) and enable modules to provide alternative streams with different lifecycles.
  2. Improve tools to create and maintain modules, which includes
    • Update and extend the tools for building modules on local host
    • Work with developers of the tools used in the Fedora infrastructure to support Modularity in their tools
  3. Improve documentation and guidelines for users and packagers, based on the feedback from the survey.
    • Work with Fedora users and packagers to ensure that we have answers for problems arising in practice
  4. Consider deeper architectural changes in Modularity. We expect to start working on this goal in spring 2021.

Deliverables

  • Fedora 33
    • Improve documentation and guidelines for users and packagers
    • Implement low-level tools for building modules locally and managing (editing, creating) modulemd data locally
    • Implement the Module Obsoletes and EOL Change to fix system upgrades (we missed the deadline, but we still want to deliver the code in F33 and modify the Change to start using it in F34)
  • Fedora 34
    • Use the Module Obsoletes and EOL Change to fix system upgrades
    • Implement the Module Context Upgrade Paths Change
    • Implement module stream switching
    • Stretch goal: Improve querying module RPMs
    • Implement tools for downloading individual modules from repositories
    • Implement tools for creating and managing repositories with modules

Objective Lead

  • Daniel Mach <dmach@redhat.com>

Objective Implementation Team

  • Martin Curlej - modularity generalist, knows a bit about MBS
  • Jaroslav Mracek - DNF
  • Ales Matej - DNF, libmodulemd
  • Jakub Kadlcik (FrostyX) - helping with low-level tools, possibly some mock/COPR integration