Modularity/Getting Started/Get involved

Introduction to the Modularization initiative in Fedora

• Modularization—here's the gist:

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 WG

Note we are all still getting organized and nothing's set in stone yet.

Get in touch

There's no dedicated mailing list yet and everything regarding this topic should be discussed on the general Fedora Development list [1]. Most of us also hang out on the #fedora-modularization channel on Freenode.

Planning

Formal meetings will be held by the Modularity Working Group, once established. See the Modularity Working Group page for more information.

We will use agile development for Modularization, using a Fedora Taiga instance [2] to manage the project. If you're not familiar with agile methodology, here are two videos to provide you an outline:

- Learn Scrum in 8 minutes - Kanban applied to Scrum

Technical details

Architecture

The current idea we're working with comprises of three main parts, some more complex than others. This can change at any point.

1. Module sources - not yet defined; these could be RPM repositories, comps files, simple component lists, COPRs, docker images...
2. A service consuming the module sources and providing digested metadata for the end clients.
3. The end clients communicating with the service, for example a standalone installation tool, a dnf plugin or a web service providing pretty module overview.

Code repositories

We currently host all of our code at Pagure [3] - the metadata service, its client, metadata drafts and even a couple of proof-of-concept modules. Repositories typically start with the fm- prefix and are open to all members of the Pagure modularization group [4].

Documentation

This differs for every project.

Documentation for the client is hosted at ReadTheDocs.org [5] and is being automatically rebuilt every 15 minutes. This will be handled by Pagure commit hooks once that feature is implemented and deployed.

Metadata service

The metadata service was deployed on a test server and populated with testing data. The client is configured to use this instance at this point.