From Fedora Project Wiki

No edit summary
m (typo)
(48 intermediate revisions by 7 users not shown)
Line 1: Line 1:
{{admon/important|This page is deprecated| All Fedora Modularity Documentation has moved to the new [https://docs.pagure.org/modularity/ Fedora Modularity Documentation website] with source hosted alongside the code in the [https://pagure.io/modularity Fedora Modularity website git repository]}}


{{autolang|base=yes}}


== Introduction ==
By way of introduction it is probably useful to try to define what we mean by "modularization."


[[File:Legoset-space.jpg|300px|right]] First of all, why do we call it "modularization?" Well, we are trying to use an agnostic term to not indicate the specific nature of a module or a component. The modules could be big or small, low or high-level, brand new or very mature. As a result, please try not to ascribe too much meaning to the word module or component aside from being a slightly prettier and shorter version of "chunk of some stuff".


Next, why are we pursuing this goal? Well, there a a lot of reasons but, I think, the simplest is to try to disconnect the lifecycle of major components from each other so that they can grow and change at the speed that is appropriate to the component. Why does that matter? Well, that is a significantly more complex conversation and somewhat beyond the scope of this document.


The first step in this project was the Fedora Rings proposal. The original proposal being adopted has resulted in a number of tangible changes with varying levels of success. The split in to the three editions, the creation of several Working Groups to further some of these goals, namely [[Env_and_Stacks|Envs & Stacks]] and [[Base]], and the creation and implementation of [https://copr.fedoraproject.org/ COPR].
 
 
 
 
 
 
 
== Summary ==
<!-- only the summary will be shown when included from other pages, ~100 words -->
<onlyinclude>
Modularity (formerly, Modularization) is an ongoing initiative in Fedora to resolve the issue of divergent, occasionally conflicting lifecycles of different components. A module provides functionality (for instance a web server) and includes well-integrated and -tested components (for instance Apache httpd and the libraries on which it depends). It can be deployed into production in various ways, for instance as "classic" RPM packages or a container image, and is updated as a whole. Different modules can emphasize new features, stability, security, etc. differently.</onlyinclude>
 
=== Modularity subsections ===
* [[Modularity/FAQ|FAQ]]
* [[Modularity/Getting_Started|Getting Started]]
* [[Modularity/Development|Development and Testing]]
* [[Modularity/Architecture|Architecture]]
* [[Modularity/User_Stories|User Stories]]
 
== Background ==
The modularity objective was introduced to Fedora as a next step to the Fedora Rings proposal. We have been through many discussions on this subject and false starts on development work. We are trying to capture what the project is and will be in this wiki page. By way of introduction it is probably useful to try to define what we mean by &quot;modularity.&quot;
[[File:Legoset-space.jpg|200px|right]] 
 
The first step in this project was the Fedora Rings proposal. The original proposal being adopted has resulted in a number of tangible changes with varying levels of success:
* The split into the three editions
* The creation of several Working Groups to further some of these goals, namely [[Env_and_Stacks|Envs &amp; Stacks]] and [[Base]]
* The creation and implementation of [https://copr.fedoraproject.org/ COPR].


However, looking at the original Fedora Rings proposal, it seems that the simple metaphor of concentric rings doesn't actually work very well for our increasingly messy open source software world. For example, there ends up being a huge number of rings to represent the whole spectrum of &quot;quality&quot; for modules. Also, the rings have problems representing orthogonal concerns like build dependencies, not to mention docs and tests. As a result, much of this discussion has stagnated trying to force fit the solution to the problem.
However, looking at the original Fedora Rings proposal, it seems that the simple metaphor of concentric rings doesn't actually work very well for our increasingly messy open source software world. For example, there ends up being a huge number of rings to represent the whole spectrum of &quot;quality&quot; for modules. Also, the rings have problems representing orthogonal concerns like build dependencies, not to mention docs and tests. As a result, much of this discussion has stagnated trying to force fit the solution to the problem.
Line 16: Line 38:
* Fedora Rings talk: for [https://mattdm.org/fedora/2013next/#1 slides] or [https://www.youtube.com/watch?v=yt2Fdbf1R_o Video]
* Fedora Rings talk: for [https://mattdm.org/fedora/2013next/#1 slides] or [https://www.youtube.com/watch?v=yt2Fdbf1R_o Video]
* 2014 Fedora Rings update: [https://mattdm.org/fedora/2014flock/#1 slides]
* 2014 Fedora Rings update: [https://mattdm.org/fedora/2014flock/#1 slides]
* A [http://video.fosdem.org/2016/janson/re-thinking-linux-distributions.mp4 recent talk] at FOSDEM 2016 and [https://m.youtube.com/watch?v=YLo7bXTRl6U Reprised] at devconf.cz 2016 and [https://langdon.fedorapeople.org/20160131-fosdem-linux-distros.html slides]
* A [http://video.fosdem.org/2016/janson/re-thinking-linux-distributions.mp4 recent talk] at FOSDEM 2016 and [https://m.youtube.com/watch?v=YLo7bXTRl6U reprised] at devconf.cz 2016 and [https://langdon.fedorapeople.org/20160131-fosdem-linux-distros.html slides]
* Concrete example: can we update docker at different speeds in, say, Fedora Atomic vs. Fedora Server? [https://lists.projectatomic.io/projectatomic-archives/atomic/2016-February/msg00014.html Mailing list thread] at projectatomic.io
* Concrete example: can we update docker at different speeds in, say, Fedora Atomic vs. Fedora Server? [https://lists.projectatomic.io/projectatomic-archives/atomic/2016-February/msg00014.html Mailing list thread] at projectatomic.io
* A talk by [[User:Byte|Colin Charles]] at FOSDEM 2016: "Distributions from the view of a package"; [http://www.slideshare.net/bytebot/distributions-from-the-view-a-package slides], unfortunately, no video.


== Context ==
== Context ==
The Modularity topic has a number of perspectives and goals, as a result, we will be posting a series of articles to the [https://communityblog.fedoraproject.org/ community blog] outlining the problems and benefits. Hopefully, separating the perspectives in to dedicated posts will make the overall story clearer. As the articles are published, we will provide links to them below.
=== Conversations ===
* [[User:Duffy|Mo Duffy]] wrote up a [https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/thread/YKYSF4S64IC5YSHFUOMC4MAKGIXPHCLP/ recap] of a server-wg meeting
* [[User:mattdm|Matthew Miller]] posted to devel [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZQV6YU54EM5YBJWTIBK4WX7KAE7Q6BN6/ asking for a minimum viable demo] of security scanning for a container-based module


=== Blog Posts ===
=== Blog Posts ===
[https://communityblog.fedoraproject.org/?s=modularity Search the blog for all Modularity posts.]
* [https://communityblog.fedoraproject.org/what-are-personas-and-why-care/ What are Personas and why should you care?]
* [https://communityblog.fedoraproject.org/introduction-to-modularity/ Introduction to Modularity]
* [https://communityblog.fedoraproject.org/modularity-infrastructure-design/ Modularity Infrastructure and Design]
* [https://communityblog.fedoraproject.org/modularity-use-case-application-independence/ Modularity Use Case: Application Independence]
* [https://communityblog.fedoraproject.org/modularization-matters-sys-admins/ Why modularization matters to Sys Admins]
=== LWN Article ===
* [https://lwn.net/Articles/679697/ Modularizing Fedora (March 16, 2016)] — Good overview from an outside-the-project perspective. (n.b. paywalled until March 31st)


== Summary of Work ==
== Summary of Work ==


* The [https://fedoraproject.org/wiki/Env_and_Stacks/Projects/PackageReviewProcessRedesign Aleph proposal] made in the E&amp;S Working Group allows for different levels of package quality.
* The [https://fedoraproject.org/wiki/Env_and_Stacks/Projects/PackageReviewProcessRedesign Aleph proposal] made in the E&amp;S Working Group allows for different levels of package quality.
* A [https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29 playgound proposal] which would combine certain COPR repositories in to one unified repository for packages that are considered more production quality than COPR but not strong enough for inclusion in the main repos. A [https://fedoraproject.org/wiki/Changes/Playground_repository Change] was also proposed.
* A [https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29 playground proposal] which would combine certain COPR repositories in to one unified repository for packages that are considered more production quality than COPR but not strong enough for inclusion in the main repos. A [https://fedoraproject.org/wiki/Changes/Playground_repository Change] was also proposed.
* See [[Modularity_Working_Group#Tooling Prototypes]] for some existing tooling prototypes.


== Fedora Objectives ==
== Fedora Objectives ==
Fedora has focused efforts related to the Modularization project through a number of [Objectives](https://fedoraproject.org/wiki/Objectives).  
Fedora has focused efforts related to the Modularization project through a number of [https://fedoraproject.org/wiki/Objectives Objectives].  


* [[Objectives/Fedora Editions, Phase 2]]
* [[Objectives/Fedora Editions, Phase 2]]
Line 41: Line 83:
** ''Timeframe'': F23 release - Flock; will be updated with subsequent phase
** ''Timeframe'': F23 release - Flock; will be updated with subsequent phase


* [[Objectives/Fedora Modularization, Prototype Phase]]
** ''Summary'': The goal of this phase is to deliver a functional implementation of modular Fedora.
** ''Objective Lead'': [[User:langdon|Langdon White]]
** ''Timeframe'': F25 release, with demo at conferences in early 2017.
== How to Get Involved ==
See [[Modularity_Working_Group|Modularity WG]] and [[Modularity/Getting_involved|Getting involved]].
[[Category:Modularity]]
[[Category:Modularization]]
[[Category:Modularization]]

Revision as of 09:02, 4 April 2017

Important.png
This page is deprecated
All Fedora Modularity Documentation has moved to the new Fedora Modularity Documentation website with source hosted alongside the code in the Fedora Modularity website git repository







Summary

Modularity (formerly, Modularization) is an ongoing initiative in Fedora to resolve the issue of divergent, occasionally conflicting lifecycles of different components. A module provides functionality (for instance a web server) and includes well-integrated and -tested components (for instance Apache httpd and the libraries on which it depends). It can be deployed into production in various ways, for instance as "classic" RPM packages or a container image, and is updated as a whole. Different modules can emphasize new features, stability, security, etc. differently.

Modularity subsections

Background

The modularity objective was introduced to Fedora as a next step to the Fedora Rings proposal. We have been through many discussions on this subject and false starts on development work. We are trying to capture what the project is and will be in this wiki page. By way of introduction it is probably useful to try to define what we mean by "modularity."

Legoset-space.jpg

The first step in this project was the Fedora Rings proposal. The original proposal being adopted has resulted in a number of tangible changes with varying levels of success:

  • The split into the three editions
  • The creation of several Working Groups to further some of these goals, namely Envs & Stacks and Base
  • The creation and implementation of COPR.

However, looking at the original Fedora Rings proposal, it seems that the simple metaphor of concentric rings doesn't actually work very well for our increasingly messy open source software world. For example, there ends up being a huge number of rings to represent the whole spectrum of "quality" for modules. Also, the rings have problems representing orthogonal concerns like build dependencies, not to mention docs and tests. As a result, much of this discussion has stagnated trying to force fit the solution to the problem.

Motivations

  • Fedora Rings talk: for slides or Video
  • 2014 Fedora Rings update: slides
  • A recent talk at FOSDEM 2016 and reprised at devconf.cz 2016 and slides
  • Concrete example: can we update docker at different speeds in, say, Fedora Atomic vs. Fedora Server? Mailing list thread at projectatomic.io
  • A talk by Colin Charles at FOSDEM 2016: "Distributions from the view of a package"; slides, unfortunately, no video.

Context

The Modularity topic has a number of perspectives and goals, as a result, we will be posting a series of articles to the community blog outlining the problems and benefits. Hopefully, separating the perspectives in to dedicated posts will make the overall story clearer. As the articles are published, we will provide links to them below.

Conversations

Blog Posts

Search the blog for all Modularity posts.

LWN Article

Summary of Work

  • The Aleph proposal made in the E&S Working Group allows for different levels of package quality.
  • A playground proposal which would combine certain COPR repositories in to one unified repository for packages that are considered more production quality than COPR but not strong enough for inclusion in the main repos. A Change was also proposed.
  • See Modularity_Working_Group#Tooling Prototypes for some existing tooling prototypes.

Fedora Objectives

Fedora has focused efforts related to the Modularization project through a number of Objectives.

  • Objectives/Fedora Editions, Phase 2
    • Summary: Take the initial Server/Workstation/Cloud split from Fedora 21 from an experiment into solid production. Increase autonomy from FESCo and improve targeted outreach.
    • Objective Lead: Stephen Gallagher
    • Timeframe: F22 and F23 releases, ending shortly after Flock 2015.

How to Get Involved

See Modularity WG and Getting involved.