Postings by Adam Samalik

Modularity question for packagers about rolling/latest/stable/master streams

Some modules now use "latest", "stable", or "master" as stream names for
various different things.

Bringing order to the confusing module stream and profile names

There are module streams named 'latest', 'stable', or 'master', but it's
not quite clear what exactly those mean. Some modules even have the
'master' and the 'latest' streams at the same time which feels quite

In a similar manner, there are various unclear profile names, too.
Especially the one called 'default', not always being the default profile.
I see a module having three profiles called 'default', 'client' and
'server', and the 'server' is the default.

Policy change: module defaults changes & Fedora Changes

The Modularity Team has published an updated policy regarding changing
module defaults and submitting Fedora Changes [1].

Simplified summary:
instead of: "Packagers must submit a Fedora Change when changing module
it now says: "Packagers should submit a Fedora Change when changing module
defaults based on their best judgement."

That brings it much closer to how we handle major changes in traditional


<a href="" title=""></a>

Querying modular content — workaround

I've just published a blog post about querying modular content [1] which
might be useful if you maintain modules.

It should help you, at least partly, in the following example scenarios:

Rebuilding dependencies after major changes
* A new version of an interpreted language lands in Fedora as a set of
standalone packages.

Topics for the Modularity WG meeting today

Sorry for the last-minute email. There are two things I'd like to discuss
today in the Modularity WG meeting [0]:

I'd like to get the "Stream default changes & Fedora Changes" [1] issue
voted on and hopefully off the table — there are already two +1s in the
ticket, and it doesn't introduce any significant changes.

The next would be "Module streams and defaults during distro upgrades" [2]
— see if we can move this forward.

Contribute to Modularity architecture discussions

Just to make sure this reaches all interested parties, we have some
important discussions about Modularity going on in Pagure tickets:

Distribution Upgrades (reaching decision) — Handling modules, streams, and
defaults during major distribution upgrades.
* Tracker: <a href="" title=""></a>
* Discussion: <a href="" title=""></a>

Module Lifecycles in General (proposal) — The general concept of defining
and managing module lifecycles.
* Tracker: <a href="" title=""></a>
* Discussion: <a href="" title=""></a>


Fedora Modularity Classroom for packagers next Tuesday

Hey all,

I'll be hosting a Fedora Modularity Classroom targeted at packagers who
want to build multiple versions of software on independent lifecycles for

When: Tuesday, October 09 at 1400 UTC
How: Bluejeans <a href="" title=""></a> (or simply dial MODULARITY)

More details:
<a href="" title=""></a>

Recording will be available on YouTube.


Removing obsolete github repositories with module definitions

We have some obsolete github repositories [1] from the f26 and f27 period
we are no longer using. I feel like it might be confusing to people. So I'd
like to remove them all. Any objections?

[1] <a href="" title=""></a>

Managing stream (arbitrary) branch and module lifecycles

This is a summary of a recent thread [1].

Traditional branches (such as "f29") have their EOL (end of life) encoded
in the name. But what about stream branches [2] (such as "2.4" or "latest")?

Stream branches of RPM packages would always have an EOL associated with

Managing module lifecycles — let's talk!

During the Modularity WG meeting yesterday [1], we've touched the topic of
module lifecycles. Even though there are some ideas in the air as well as
some code written, we haven't reached a state in which we would know how
exactly to deal with it. So I'd like to discuss it here with a wider
audience, and review it again in the next Modularity WG meeting.

== Introduction: (feel free to skip this if you know what I'm talking about)

In concept, modules live more or less independently from the Fedora

Creating modules — docs updates

There have been some recent updates to the Making Modules section in Fedora
Docs [1], especially Adding new Modules [2] and Defining Modules in
modulemd [3] which will guide you through the whole process of creating a
new module in Fedora. So I thought it's worth pointing out here.

Modularizing the world fast and iteratively

Starting with a summary: ​Let's 1) use something like dependency-report
scripts [1] to get coordinated, and 2) make the initial builds against
bootstrap so we get a working thing fast and can iterate.

I've realized that developing the initial set of modules for F27 could be a
bit tricky in the beginning as some things might require many basic
dependencies on top of Platform to run and build.

First round of Boltron feedback published

The Modularity team has published a first round of Boltron feedback:
<a href="" title=""></a>

Feedback is still being collected using the Boltron Walkthrough and UX
feedback form: <a href="" title=""></a>

Building modules works with a little hack

Short version:

If you want to build a module, edit your modulemd file, change
"base-runtime" to "bootstrap" in dependencies, commit your change locally
and continue as you would before - that means use the "build-module" script
described on our documentation website [1] .

Long version:

We had some troubles recently with building our modules as the
"base-runtime" module - a (build) dependency for all other modules - has
been deleted from the infra.

New documentation website

We have moved the documentation of the Modularity project from wiki [1] to
Pagure Docs [2]!

The documentation is build using Python Sphinx with custom theme that also
includes the home page. To edit the documentation, please send
pull-requests against the source repository [3].

[1] <a href="" title=""></a>
[2] <a href="" title=""></a>
[3] <a href="" title=""></a>

Modularity basics - animations

Hey everyone,

I have created two animations describing the basic concepts of modularity:

1) Fedora Modularity basic concepts
<a href="" title=""></a>
2) What is a module? <a href="" title=""></a>

You can also find the same ones as an SVG animations here:
<a href="" title=""></a>

BPO - the great UI that shows you everything

Hi everyone,

I would like to hear your opinion/need your help!

I am working on a component of the Fedora Modularity[1] project, called
Build Pipeline Overview (BPO). It will be a single user interface (probably
both web and API) that would give you information about "everything". And
I would like your help with defining what that "everything" means.

To make the definition of "everything" easier, we are using a concept of

Fedora Developer Portal - update

I have just updated the Fedora Developer Portal with the following content.
Big thanks to everyone who contributed!

What's new:

- Eclipse
<a href="" title=""></a>
by Alexander Kurtakov

- Maintain and Improve
<a href="" title=""></a>
by Petr Hracek

- Secondary Architectures

<a href="" title=""></a>
by Sinny Kumari

- Jekyll
<a href="" title=""></a>
by Jakub Kadlcik

- Laravel 5
<a href="https://developer.fedor" title="https://developer.fedor">https://developer.fedor</a>

Preparing a new release of Fedora Developer Portal - asking for feedback

Hello Everyone,

we have prepared a new release of Fedora Developer Portal, and we would
like to hear your feedback before pushing it into production. If everything
goes fine, we would like to make the release on Monday, April 25th.

This email is the first of its kind. I would like to send it every time
before release - to make sure, that we involve everyone who might be
interested. This time, I have also cc-ed 'websites' and 'devel' lists.

Fedora Developer Portal Update

Hi everyone,

this is an update about the new Fedora Developer Portal project [1]:

* The design implementation is almost done. See it live on
<a href="" title=""></a>. Big thanks to Máirín Duffy! There
are still some minor issues [2] to solve - we'll welcome any help with

* We are now finishing the technical implementation for our first
milestone [3] - i.e.