cannot

I'd like to see a vote on this delayed until after Flock and when the TBD sections are filled out based on the Flock hackfest.

I like this proposal, however I would like to point to one thing.

In the goals section you are talking about improving packager experience and experience of creating modules for packagers. But I could not find anywhere in deliverables anything about "create tooling for automated creation of modules which is run as part of Fedora". For example:

• I push to rust-regex rpm repo
• Some tooling detects that it is used by ripgrep and zola modules
• And regenerates modulemd (or delivers the change in some other way)
• And builds new version of a module

Nowadays, it consumes quite a lot of time for me to maintain 30+ Rust modules.

Do you think it is feasible to add on the roadmap?

It seems like dnf will need a lot of changes. Is the dnf team on board? cc @jmracek

Before encouraging people to make modules, can you please resolve the upgrades first? https://pagure.io/modularity/issue/151
This has been the most common issue during upgrades from F30 to F31 and there is known workaround but not known general solution yet.

This is technically possible for a long time. Mock can install and enable modules in buildroot. Therefore it is just a matter of having the right config in Koji. I would be more specific here. What you are trying to do, technically.

Can we make this part of the objective? https://pagure.io/fesco/issue/2114

Should we stop modularizing libraries and focus on "leaf stacks" instead?

There must be strong restrictions to create modules, because each module will increase demands for release engineering, infrastructure and testing.
At present there are multiple reports about broken dependencies between nonmodular content and enabled modules and their dependencies on systems that never used dnf module commands (consequence of enablement of defaults and their dependencies).
Wee need to focus on QE and testing all module streams combinations to ensure integrity of distribution (modular repoclosure).

It is blocked by rejection of https://src.fedoraproject.org/rpms/libsolv/pull-request/4.
See also https://bugzilla.redhat.com/show_bug.cgi?id=1737469

We need to provide an alternative approach how to resolve system-upgrade in fedora. I do not agree to use "Rolling Defaults", because it is a fragile construct that makes modularity more complicate and not transparent.

Is this a fail-safe mechanism? The fail-safe mechanism is ready to deploy.

I do not understand that, sorry.

Any significant changes must be ready before 2020-02-25 - Beta freeze

There must be strong restrictions to create modules, because each module will increase demands for release engineering, infrastructure and testing.
At present there are multiple reports about broken dependencies between nonmodular content and enabled modules and their dependencies on systems that never used dnf module commands (consequence of enablement of defaults and their dependencies).
Wee need to focus on QE and testing all module streams combinations to ensure integrity of distribution (modular repoclosure).

+1

Complaints about dependency issues with enabled modules, when the users did not know modularity existed and they never had used any modular command, are numerous. Maybe modules should only be used when explicitly required by the user? Such approach would prevent a lot of discussed problems per se.

We need to provide an alternative approach how to resolve system-upgrade in fedora. I do not agree to use "Rolling Defaults", because it is a fragile construct that makes modularity more complicate and not transparent.

If we did not allow modules to have a default stream, we could still maintain the ursine packages for the default version of the available software. In that case, people who wouldn't be interested in modules could remain on a non-modular content (they are trying to do it anyway), without any problems with upgrades. The others, who'd like to use modules, could do it and they would be expected to know how to solve the upgrades by themselves.

I feel, that there is a longing for modular only system, but I am not sure that we are able to test that different modular streams do not break mutual dependencies. With most of the software in modules, with possibly multiple streams, there will be bazillion of different combinations and I am afraid we do not have enough human and machine power to test everything thoroughly.

What we also need urgently are clear guidelines how to create modules, so that the streams and profiles are correctly set (or even named). These guidelines should also be enforced and modules that do not meet the criteria should not be let into the system ( => gating).

Maybe introducing an automated tool that would take care of it is a good idea, so I am in favor of +1 to @ignatenkobrain .

If we abandon the idea of default streams everything will indeed get much easier for the users. As a bonus, we don't have to do ursa prime.

That indeed has my full support. The default version should be nonmodular. Modules should provide alternate versions for people who want them.

That indeed has my full support. The default version should be nonmodular. Modules should provide alternate versions for people who want them.

The problem with this approach that this "alternative version" maintenance workflow would be different. We either need to have same workflow for standard and alternative versions or we should not have modularity. Trying to be somewhere in the middle is not going to end up well.

We can fix the users experience + regular packager experience first and worry about the modular contributor experience later? If the experience is "nah, this is too complicated", we would still have the default nonmodular version.

We can fix the users experience + regular packager experience first and worry about the modular contributor experience later? If the experience is "nah, this is too complicated", we would still have the default nonmodular version.

I believe that users experience should be our mantra, because we do not want to make users leaving for other distros. So, for every technology we want to adopt into Fedora, we must nourish it into perfectness or think about something else.

If staying in the middle only represents some extra work to package the modules, I think it is a reasonable cost. The non-modular workflow is known, experienced, tested and trusted, so we do not have to do much in this field and we can focus on making the modular workflow as pleasant as possible while still staying in the middle.

By the way, I like staying in the middle because it is far from every extreme.

The plan also forget to talk about:
1. Module or stream removal process from distribution (EOL)
2. Life-cycle of the stream
3. Modular upgrade path - missing documentation and tooling
4. What about module:streams obsoletes?

The ownership of Modularity development within Red Hat has changed. So we're retiring the current Modularity objective and work with the new team to develop a new one.