DevHeads.net

Renewing the Modularity objective

Now that Modularity is available for all Fedora variants, it's time to
address issues discovered and improve the experience for packagers and
users. The Modularity team identified a number of projects that will
improve the usefulness of Modularity and the experience of creating
modules for packagers. Thoe team is proposing a renewed objective to
the Fedora Council.

You can read the proposal at:
<a href="https://pagure.io/Fedora-Council/council-docs/pull-request/61#request_diff" title="https://pagure.io/Fedora-Council/council-docs/pull-request/61#request_diff">https://pagure.io/Fedora-Council/council-docs/pull-request/61#request_diff</a>

The Council will vote on this in two weeks.

This is also posted to the Community Blog:
<a href="https://communityblog.fedoraproject.org/renewing-the-modularity-objective/" title="https://communityblog.fedoraproject.org/renewing-the-modularity-objective/">https://communityblog.fedoraproject.org/renewing-the-modularity-objective/</a>

Comments

Re: Renewing the Modularity objective

By =?UTF-8?Q?Ji=C5... at 09/23/2019 - 04:55

Hello,

Could you please also resolve breaking upgrade paths for people who
never run `dnf module` command?

I'll try to explain what happened to me. As I wrote above I never run
`dnf module` until I was forced to run `dnf module reset` to fix my
issue. I'm running Fedora 30.

If I understand correctly what happened was that my zanata-client
package switched to module (or maybe dependencies, not sure) and then
the module was removed and replaced by packages.

It happened like this:

1) `dnf update` updated zanata to use module
2) module was removed
3) `dnf update` has conflict with module packages because it tried to
update to non module packages which were in conflict with the module
installed ones
4) Had to call my first module command and that was `dnf module reset`
5) Call `dnf distrosync` to remove the packages from a non-existing
module
6) Finally working `dnf update`

This is really not nice user experience to start with the modules from
a user perspective. Could you please prevent this issue for future.
There should be a way how to remove module without blocking upgrade
path, especially when the module was automatically dragged in by a
normal update.

What I missed in the above for simplification is that I used the `
--best --allowerasing` with a hope that I will be able to install the
new zanata then. By doing that I've effectively blocked zanata-client
from being installed on my laptop.

I also want to thank DNF team, they helped me to fix my NB otherwise I
wouldn't be able to make a new releases thanks to the missing zanata-
client.

Best regards,
Jirka

On Wed, 2019-09-18 at 15:30 -0400, Ben Cotton wrote:

Re: Renewing the Modularity objective

By Kevin Fenzi at 09/22/2019 - 17:10

On Wed, Sep 18, 2019 at 03:30:58PM -0400, Ben Cotton wrote:
Is it really good to replace the old objective with the new one?
Shouldn't we archive off that one and call this one something else so
you can see what was done when?

Did you want comments here or on the PR? Or both?
(I see a number of folks have commented on the PR... which is awesome!)

I really like the goals/ideas here. We definitely need to improve
modules.

kevin

Re: Renewing the Modularity objective

By Matthew Miller at 09/24/2019 - 10:14

On Sun, Sep 22, 2019 at 02:10:11PM -0700, Kevin Fenzi wrote:
Possibly! We've done the modularity objective in phases so far, with greater
and lesser attention to tying off some of the different phases. Do you have
a suggestion for an alternate name?

Big picture comments here, details on the PR?

Re: Renewing the Modularity objective

By Michal Schorm at 09/19/2019 - 07:55

I'd suggest that the Modularity team could preapre a list of example
use cases that will present the strenghts of the modularity.
I believe, there are currently many examples of packages that took a
path to become only modular and it always created more issues than it
solved.
Let's focus on a simple use cases first, which only modularity can
solve the best and leave the more complicated ones for later - after a
careful consideration if turning some regular packages into only
modules would really help both packager and user experience.

Keep in mind, there are still wide gaps in the modularity packager
experience, new bugs spawning every now and then.
In light of this persistent situation, I honor the new goal currently
set of focusing at those issues.

Re: Renewing the Modularity objective

By Jun Aruga at 09/19/2019 - 08:48

I just share below my project for me to investigate use cases to
switch a modules stream with Fedora (and RHEL) container and Travis
CI.
It's not general module examples but only examples to switch a module.
But I believe that the way to show the example with actual command
lines with the Fedora container and Travis CI helps someone to
advocate the list of the example use cases.

<a href="https://github.com/junaruga/switch-module-stream" title="https://github.com/junaruga/switch-module-stream">https://github.com/junaruga/switch-module-stream</a>

Re: Renewing the Modularity objective

By Petr Pisar at 09/19/2019 - 08:31

On 2019-09-19, Michal Schorm < ... at redhat dot com> wrote:
If you build it for all Fedoras, how do you deal with incompatible
changes during the MySQL 8 developement. I'm hitting on the Fedora
Updates Policy that forbids incompatible changes in stable Fedoras.

If you build it for Rawhide only, how do you ensure that the module is
not inheritted into a stable Fedora on branching. Because in case of
branching F31 relengs tried very hard to branch the module and rebuild
them. (Despite I told them not to do that with perl:5.26.)

I'm still missing an offical recognition that there can be modules under
development in stable Fedora. Otherwise we have no way of developing new
modules. Fedora tries very hard to align module lifecycle to Fedora
lifecycle. It does not work for me.

-- Petr

Re: Renewing the Modularity objective

By Stephen Gallagher at 09/24/2019 - 10:56

On Thu, Sep 19, 2019 at 8:33 AM Petr Pisar < ... at redhat dot com> wrote:

I just opened <a href="https://pagure.io/modularity/issue/156" title="https://pagure.io/modularity/issue/156">https://pagure.io/modularity/issue/156</a> to make a proper
policy decision on this, including my recommendation:

***
* It is not permissible to make a prerelease stream the default stream
for a module in any release.(*)
* It is permissible to include a pre-release stream in Rawhide at any time.
* It is permissible to include a pre-release stream in a stable branch
of Fedora if the stream name clearly identifies it as unstable in some
manner. When the stream is ready to be treated as stable, a new stream
should be created with an [appropriate
name](<a href="https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-guidelines/#_module_stream_name" title="https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-guidelines/#_module_stream_name">https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-gu...</a>)
(such as a version number or other indicator of API/UX compatibility).

(*) Note that this is different from a "rolling" stream, in that the
expectation on rolling streams are that all of the updates are stable,
not that they are experimental and might change.
***

Re: Renewing the Modularity objective

By Michal Schorm at 09/19/2019 - 08:44

That's a great observation.
Ususally when the package (module in this case) is prone to breaking
bugs, I develop it in Rawhide and only later, (e.g. Beta, but it
depends from upstream to upstream) I extend the build to other
Fedoras.

That's surely an *absolute need* to have an option to mark a module as
"under developement" or something simmilar and have that anchored in
the guidelines, if we want to use this chance a modularity technically
offers.