Modularity

Click here to set up this language box

Introduction

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

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 Envs & Stacks and Base, and 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

Summary of Work

• The Aleph proposal made in the E&S Working Group allows for different levels of package quality.
• A 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 Change was also proposed.

Fedora Objectives

Fedora has focused efforts related to the Modularization project through a number of [Objectives](https://fedoraproject.org/wiki/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.

• Objectives/Fedora Modularization, Requirements Phase
  • Summary: Requirements-gathering from stakeholders for "Rings" aspect of Fedora.next
  • Objective Lead: Langdon White
  • Timeframe: F23 release - Flock; will be updated with subsequent phase