What are the benefits of default modular streams over non-modular packages?

[Miro Hrončok]

Hello, in this thread (Fedora 32 System-Wide Change proposal: Modules in 
Non-Modular Buildroot)

https://lists.fedoraproject.org/archives/list/[e-mail].o...

I've asked whether it wouldn't be in fact much easier to keep the default 
versions of our packages non-modular.

Others have said they are interested in this as well. A huge thread happened but 
it hasn't delivered an answer.
Arguments were made that default modular streams are planned to deliver the 
exact same experience as non-modular packages, yet it was not said if it 
wouldn't be easier to just deliver non-modular packages for default versions.

Maybe it would be helpful to try to reformulate the question:


**What are the benefits of default modular streams over non-modular packages?**


I'll admit that I personally don't see any benefits, but of course that
doesn't 
mean that they don't exist or that it's not worth having this discussion.

Considering we have 6 default modular streams, let me acknowledge that for the 
maintainers who decided to deliver default modular streams instead of 
non-modular packages, there clearly are some benefits.
While some of us might not understand them, let's not say there are none. But 
even if there are clear benefits for the maintainers of those modules, I'm 
asking about the benefits for everybody else.

I'm mainly interested in benefits for:
  - Fedora users
  - Fedora non-modular packagers
  - Fedora QA
  - Fedora Release Engineering
  - Community Platform Engineering Team
  - Fedora downstream

To get the most out of this discussion I think it's useful to set a few rules, 
similarly to the official modularity complaint thread:

https://lists.fedoraproject.org/archives/list/[e-mail].o...

So let's set some rules:

1. Always assume good faith. If you are not sure, ask clarifying questions.

2. No complaints. This thread is about benefits. Use the complaint thread for 
complaints.

3. Any vague speculative benefits will be ignored. "I think that having default 
modular streams sends a better message about how we are a progressive 
distribution" is an example of a speculative statement. Always be try to be 
concrete about who benefits, how and by what means.

4. Any argument based on the already spent money/time/energy to deliver default 
modular streams is to be ignored. It's a classic example of a sunk cost fallacy. 
"I think we need default modular streams because people have been working really 
hard to make them happen" is an example of such argument.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Fabio Valentini]

On Thu, Nov 14, 2019 at 4:57 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  Hello, in this thread (Fedora 32 System-Wide Change proposal: Modules in
>  Non-Modular Buildroot)
>
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>
>  I've asked whether it wouldn't be in fact much easier to keep the default
>  versions of our packages non-modular.
>
>  Others have said they are interested in this as well. A huge thread happened but
>  it hasn't delivered an answer.
>  Arguments were made that default modular streams are planned to deliver the
>  exact same experience as non-modular packages, yet it was not said if it
>  wouldn't be easier to just deliver non-modular packages for default versions.
>
>  Maybe it would be helpful to try to reformulate the question:
>
>
>  **What are the benefits of default modular streams over non-modular packages?**
>
>
>  I'll admit that I personally don't see any benefits, but of course that
> doesn't
>  mean that they don't exist or that it's not worth having this discussion. 
(snip)

>  Considering we have 6 default modular streams, 
Just to make this explicit for the people who don't know how to
determine this themselves (which includes me):
Which six modules do provide a default stream? I can't seem to tell by
looking at any modules' yaml files.

I hope this counts as a clarifying question, and not as a negative
"this is difficult to figure out" criticism ;)

Fabio

> let me acknowledge that for the
> maintainers who decided to deliver default modular streams instead of
> non-modular packages, there clearly are some benefits.
> While some of us might not understand them, let's not say there are none. But
> even if there are clear benefits for the maintainers of those modules, I'm
> asking about the benefits for everybody else.
>
> I'm mainly interested in benefits for:
>   - Fedora users
>   - Fedora non-modular packagers
>   - Fedora QA
>   - Fedora Release Engineering
>   - Community Platform Engineering Team
>   - Fedora downstream
>
> To get the most out of this discussion I think it's useful to set a few rules,
> similarly to the official modularity complaint thread:
>
>
https://lists.fedoraproject.org/archives/list/[e-mail].o...
>
> So let's set some rules:
>
> 1. Always assume good faith. If you are not sure, ask clarifying questions.
>
> 2. No complaints. This thread is about benefits. Use the complaint thread for
> complaints.
>
> 3. Any vague speculative benefits will be ignored. "I think that having default
> modular streams sends a better message about how we are a progressive
> distribution" is an example of a speculative statement. Always be try to be
> concrete about who benefits, how and by what means.
>
> 4. Any argument based on the already spent money/time/energy to deliver default
> modular streams is to be ignored. It's a classic example of a sunk cost fallacy.
> "I think we need default modular streams because people have been working
really
> hard to make them happen" is an example of such argument.
>
> --
> Miro Hrončok
> --
> Phone: [phone]
> IRC: mhroncok
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

[Miro Hrončok]

On 14. 11. 19 17:22, Fabio Valentini wrote:
>  On Thu, Nov 14, 2019 at 4:57 PM Miro Hrončok
> <mhroncok(a)redhat.com&gt; wrote:
> >
> > Hello, in this thread (Fedora 32 System-Wide Change proposal: Modules in
> > Non-Modular Buildroot)
> >
> >
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
> >
> > I've asked whether it wouldn't be in fact much easier to keep the default
> > versions of our packages non-modular.
> >
> > Others have said they are interested in this as well. A huge thread happened but
> > it hasn't delivered an answer.
> > Arguments were made that default modular streams are planned to deliver the
> > exact same experience as non-modular packages, yet it was not said if it
> > wouldn't be easier to just deliver non-modular packages for default versions.
> >
> > Maybe it would be helpful to try to reformulate the question:
> >
> >
> > **What are the benefits of default modular streams over non-modular packages?**
> >
> >
> > I'll admit that I personally don't see any benefits, but of course that
> doesn't
> > mean that they don't exist or that it's not worth having this discussion.
>  
>  (snip)
>  
> > Considering we have 6 default modular streams,
>  
>  Just to make this explicit for the people who don't know how to
>  determine this themselves (which includes me):
>  Which six modules do provide a default stream? I can't seem to tell by
>  looking at any modules' yaml files. 
I've took that number from the document linked in:

https://pagure.io/fesco/issue/2255#comment-610332

It lists the following 6 modules:

dwm:6.2
avocado:69lts
scala:2.10
ant:1.10
gimp:2.10
maven:3.5

It also lists the eclipse module as a potential candidate. I've decide not to 
count it, because at the same time, gimp is dropping the default in:

https://bugzilla.redhat.com/show_bug.cgi?id=1772469

So either way, we are at 6.

I thing the canonical source of this data is:

https://pagure.io/releng/fedora-module-defaults/tree/master

If I understand the format correctly, the yamls that have the stream key have 
default.

   [fedora-module-defaults (master)]$ rg -F -g '!tests' 'stream: '
   ant.yaml
   5:    stream: 1.10

   dwm.yaml
   6:    stream: 6.2

   gimp.yaml
   5:    stream: 2.10

   scala.yaml
   5:    stream: 2.10

   maven.yaml
   5:    stream: 3.5

   avocado.yaml
   5:    stream: 69lts


>  I hope this counts as a clarifying question, and not as a negative
>  "this is difficult to figure out" criticism ;) 
It does count as clarifying question :)

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Stephen Gallagher]

On Thu, Nov 14, 2019 at 11:39 AM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:

>  I thing the canonical source of this data is:
>
>  https://pagure.io/releng/fedora-module-defaults/tree/master
>
>  If I understand the format correctly, the yamls that have the stream key have
>  default. 
For the record, you are correct. This is the canonical way to
determine what has defaults (other than doing `dnf module list` and
looking through it for [d] in the streams).

[Gordon Messmer]

On 11/14/19 7:56 AM, Miro Hrončok wrote:
>  **What are the benefits of default modular streams over non-modular 
>  packages?**  

I think Adam Williamson tried to answer that in a message in the thread 
"Re: Modularity and the system-upgrade path" (link below) when he wrote:

"if you just don't modularize FreeIPA ... we're stuck shipping this one 
version of FreeIPA for the next seventy jillion years"

I didn't really understand that, but maybe he'll clarify (possibly 
again) in this thread.

I think I don't understand what he meant because I'm not clear on what 
he meant to imply would happen when the default module changes.  Perhaps 
the idea is that nothing happens.  The packages in that module just stop 
getting updates and it's up to the end user to enable a new module and 
migrate their data.  That could, conceivably, be seen as better than 
rebasing the packages on a new version that requires a data migration 
that can't reliably be done automatically.

That's speculation on my part, however, and it's inconsistent with the 
behavior that Stephen described in the first message in that thread, 
which was "When running `dnf update` or `dnf system-upgrade`, if the 
default stream for a module installed on the system changes and the 
module's current state is `default_enabled`, then the transaction should 
cause the new default stream to be enabled."  And I'm not sure how 
that's different or better than simply rebasing, as RHEL sometimes does.

Anyway, among the messages I've read in the earlier threads, Adam's came 
closest to answering this question, so I hope he'll weigh in again.

https://lists.fedoraproject.org/archives/list/[e-mail].o...

[Miro Hrončok]

On 15. 11. 19 2:56, Gordon Messmer wrote:
>  On 11/14/19 7:56 AM, Miro Hrončok wrote:
> > **What are the benefits of default modular streams over non-modular packages?** 
>  
>  
>  I think Adam Williamson tried to answer that in a message in the thread "Re: 
>  Modularity and the system-upgrade path" (link below) when he wrote:
>  
>  "if you just don't modularize FreeIPA ... we're stuck shipping this one
> version 
>  of FreeIPA for the next seventy jillion years" 
That I understood as a RHEL benefit, a solution to a RHEL problem.

We even put Python 2 to a module, so we don't need to support it that long.

Fedora is not supported for jillions of years, but 13 months.
Fedora has a hard rule that (default?) modular EOLs must align with Fedora 
release EOL.

So I don't see how this benefit applies for Fedora.

Thanks for the pointer anyway!

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Joe Orton]

On Thu, Nov 14, 2019 at 04:56:28PM +0100, Miro Hroncok wrote:
>  I'll admit that I personally don't see any benefits, but of
> course that
>  doesn't mean that they don't exist or that it's not worth having this
>  discussion.
>  
>  Considering we have 6 default modular streams, let me acknowledge that for
>  the maintainers who decided to deliver default modular streams instead of
>  non-modular packages, there clearly are some benefits.
>  While some of us might not understand them, let's not say there are none.
>  But even if there are clear benefits for the maintainers of those modules,
>  I'm asking about the benefits for everybody else. 
Seems like a bit of an odd question.  There is an end-user benefit from 
making multiple module streams available both in the short run (more 
features/choices today) and long run (better tested software via making 
development/unstable releases available more widely).

This comes at a high cost to package owners if we have to keep 
non-modular packages - we have to maintain, build, and test X streams 
plus Y non-modular release branch builds for each component, rather than 
just X streams.  In some cases the costs will be prohibitive to 
supporting modular streams - the aim of switching to default streams + 
dropping non-modular packages is precisely to eliminate that cost 
difference.

Regards, Joe

[Miro Hrončok]

On 15. 11. 19 12:14, Joe Orton wrote:
>  On Thu, Nov 14, 2019 at 04:56:28PM +0100, Miro Hroncok wrote:
> > I'll admit that I personally don't see any benefits, but of course that
> > doesn't mean that they don't exist or that it's not worth having this
> > discussion.
> >
> > Considering we have 6 default modular streams, let me acknowledge that for
> > the maintainers who decided to deliver default modular streams instead of
> > non-modular packages, there clearly are some benefits.
> > While some of us might not understand them, let's not say there are none.
> > But even if there are clear benefits for the maintainers of those modules,
> > I'm asking about the benefits for everybody else.
>  
>  Seems like a bit of an odd question.  There is an end-user benefit from
>  making multiple module streams available both in the short run (more
>  features/choices today) and long run (better tested software via making
>  development/unstable releases available more widely). 
I don't understand how are default modular streams valuable to that benefit.

(let's have a lamafarm software in the examples)

Suppose I have this situation:

- lamafarm version 1.x is in default modular stream only
- there are no other streams with other versions of lamafarm

Vs. this situation:

- lamafarm version 1.x is in non-modular Fedora
- there are no modular streams with other versions of lamafarm

Where is the end-user benefit with the modular default stream? I don't see it, 
sorry.


Or suppose I have this situation:

- lamafarm version 1.x is in default modular stream only
- there are N other streams with other versions of lamafarm (such as 2.x, ...)

Vs. this situation:

- lamafarm version 1.x is in non-modular Fedora
- there are N moulear streams with other versions of lamafarm (such as 2.x, ...)

Where is the end-user benefit with the modular default stream? I don't see it 
either, sorry.


>  This comes at a high cost to package owners if we have to keep
>  non-modular packages - we have to maintain, build, and test X streams
>  plus Y non-modular release branch builds for each component, rather than
>  just X streams. 
Yes. This is the benefit of the default modular stream for the modular 
maintainers. I have never questioned it.

I have even proposed that we take the default modular stream RPMs and we add 
them to our non-modular repository when we compose it, in order to keep that 
benefit for the modular maintainers. It was turned down almost immediately.

>  In some cases the costs will be prohibitive to
>  supporting modular streams - the aim of switching to default streams +
>  dropping non-modular packages is precisely to eliminate that cost
>  difference. 
In my opinion (and that is my very subjective opinion, but based on experience) 
the cost of that difference is otherwise paid by everybody else.

The group of everybody else is very much bigger than the group of modular 
maintainers. Hence, I'd approve such trade off.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Joe Orton]

On Fri, Nov 15, 2019 at 12:44:52PM +0100, Miro Hroncok wrote:
>  Where is the end-user benefit with the modular default stream? I
> don't see
>  it either, sorry. 
It's not clear to me how those examples are related to my argument, 
which I could summarize as:

a) multiple module streams have a benefit to users, and
b) default streams have a benefit to package owners.

>  > This comes at a high cost to package owners if we have to keep
>  > non-modular packages - we have to maintain, build, and test X streams
>  > plus Y non-modular release branch builds for each component, rather than
>  > just X streams.
>  
>  Yes. This is the benefit of the default modular stream for the modular
>  maintainers. I have never questioned it. 
OK great, though it is a bit surprising to hear in a thread which you 
started explicitly to question the benefits of default modular streams.

>  In my opinion (and that is my very subjective opinion, but based on
>  experience) the cost of that difference is otherwise paid by everybody else.
>  
>  The group of everybody else is very much bigger than the group of modular
>  maintainers. Hence, I'd approve such trade off. 
So it's clear to me that you see that packagers chosing default streams 
over non-modular packages impose external costs on the rest of the 
distro (packagers and/or users?) somehow.  This thread was supposed to 
focus on benefits, and these vague claims about costs and trade-offs 
seem speculative, but maybe you could expand on that a bit?

Perhaps this stuff is obvious to others already.  In RHEL8 while we have 
certainly hit various problems with modularity at least I don't recall 
my teams hitting major issues with default streams being available for 
non-modular packages.

Regards, Joe

[Igor Gnatenko]

On Fri, Nov 15, 2019 at 3:38 PM Joe Orton <jorton(a)redhat.com&gt; wrote:
>  On Fri, Nov 15, 2019 at 12:44:52PM +0100, Miro Hroncok wrote:
>  > Where is the end-user benefit with the modular default stream? I don't see
>  > it either, sorry.
>
>  It's not clear to me how those examples are related to my argument,
>  which I could summarize as:
>
>  a) multiple module streams have a benefit to users, and
>  b) default streams have a benefit to package owners. 
You quoted Miro above, "end-user benefit". He is not talking about
packaging experience here, which is pretty bad with modules.

>  > > This comes at a high cost to package owners if we have to
> keep
>  > > non-modular packages - we have to maintain, build, and test X streams
>  > > plus Y non-modular release branch builds for each component, rather than
>  > > just X streams.
>  >
>  > Yes. This is the benefit of the default modular stream for the modular
>  > maintainers. I have never questioned it.
>
>  OK great, though it is a bit surprising to hear in a thread which you
>  started explicitly to question the benefits of default modular streams.
>
>  > In my opinion (and that is my very subjective opinion, but based on
>  > experience) the cost of that difference is otherwise paid by everybody else.
>  >
>  > The group of everybody else is very much bigger than the group of modular
>  > maintainers. Hence, I'd approve such trade off.
>
>  So it's clear to me that you see that packagers chosing default streams
>  over non-modular packages impose external costs on the rest of the
>  distro (packagers and/or users?) somehow.  This thread was supposed to
>  focus on benefits, and these vague claims about costs and trade-offs
>  seem speculative, but maybe you could expand on that a bit?
>
>  Perhaps this stuff is obvious to others already.  In RHEL8 while we have
>  certainly hit various problems with modularity at least I don't recall
>  my teams hitting major issues with default streams being available for
>  non-modular packages. 
Because they just have to do it, they don't have option to choose
technology. They get paid to do their job.

>
> Regards, Joe
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

[Zbigniew Jędrzejewski-Szmek]

On Fri, Nov 15, 2019 at 02:30:20PM +0000, Joe Orton wrote:
>  On Fri, Nov 15, 2019 at 12:44:52PM +0100, Miro Hroncok wrote:
>  > Where is the end-user benefit with the modular default stream? I don't see
>  > it either, sorry.
>  
>  It's not clear to me how those examples are related to my argument, 
>  which I could summarize as:
>  
>  a) multiple module streams have a benefit to users, and
>  b) default streams have a benefit to package owners. 
Hi Joe,

this thread is looking for details about a very specific question:
What are the benefits of default modular streams over non-modular packages?
(and as clarified in text: for everybody else, not the maintainers of those
modules). We also want to be as concrete as possible, to avoid getting
mired in speculation.

If I understood your argument, you are saying that default module
streams make it easier for the owners of those modules to deliver rpms
(as compared to providing non-modular rpms), and that this indirectly
benefits users because they get those rpms faster and will less maintainer
effort. Did I get this right?

If there's some other benefit, please describe a specific scenario.

Zbyszek

[Fabio Valentini]

On Fri, Nov 15, 2019 at 3:31 PM Joe Orton <jorton(a)redhat.com&gt; wrote:
>  On Fri, Nov 15, 2019 at 12:44:52PM +0100, Miro Hroncok wrote:
>  > Where is the end-user benefit with the modular default stream? I don't see
>  > it either, sorry. 
Let me offer a second opinion (coming from some first-hand experience) here:

>  It's not clear to me how those examples are related to my
> argument,
>  which I could summarize as:
>
>  a) multiple module streams have a benefit to users, and 
I think this is a valid point, and it's one of the biggest benefits of
Modularity. But default streams are orthogonal to this.

>  b) default streams have a benefit to package owners. 
This, however, is not true for fedora in my experience (it may be true
for RHEL, though).
See my explanation below.

>  > > This comes at a high cost to package owners if we have to
> keep
>  > > non-modular packages - we have to maintain, build, and test X streams
>  > > plus Y non-modular release branch builds for each component, rather than
>  > > just X streams.
>  >
>  > Yes. This is the benefit of the default modular stream for the modular
>  > maintainers. I have never questioned it. 
I don't even think that it's a (big) benefit for modular maintainers.

>  OK great, though it is a bit surprising to hear in a thread which
> you
>  started explicitly to question the benefits of default modular streams. 
Ok, let's say you're maintaining default streams for 3-4 fedora
branches instead of 3-4 fedora branches "separately". I disagree that
this makes maintenance easier for the package owner *in general*.

Since there are inherent differences between the fedora "base systems"
in the different branches, one of the following things must be true:
- Either there will have to be a different default stream for some
fedora releases (making you maintain multiple branches anyway), or
- you will need %if%else%endif spaghetti in your .spec files to
support all branches of fedora you target at once.

Is this "easier" than using the clean separation provided by git
branches for non-modular packages ? Probably not.
(But hey, some maintainers do like their %if%else%endif spaghetti
because they want to git merge stuff from rawhide downwards. I don't.)

>  > In my opinion (and that is my very subjective opinion, but based
> on
>  > experience) the cost of that difference is otherwise paid by everybody else.
>  >
>  > The group of everybody else is very much bigger than the group of modular
>  > maintainers. Hence, I'd approve such trade off. 
I agree. This is very much in line with the "be excellent to each other" maxim.
Making my own work easier at the expense of making things worse for
everybody else who depends on my stuff is most definitely not
"excellent".

>  So it's clear to me that you see that packagers chosing default
> streams
>  over non-modular packages impose external costs on the rest of the
>  distro (packagers and/or users?) somehow.  This thread was supposed to
>  focus on benefits, and these vague claims about costs and trade-offs
>  seem speculative, but maybe you could expand on that a bit? 
I can provide one example (or two).

Probably the worst "offender" here is the "maven" module. The
original
maintainers of most Java packages decided to drop all their
"non-modular" packages and leave them to bitrot (side note: the bitrot
started happening in 2017, but it got much worse in 2019, when
packages were starting to get retired after 6 weeks of being
orphaned). This situation also forced eclipse into becoming a module,
because many of their dependencies were now effectively unmaintained
or broken. It was also the explicit reason for the founding of the
Stewardship SIG - to make sure at least basic Java packaging stuff is
still working (otherwise, LibreOffice would now be broken in fedora
31+).

Also, currently, the "maven:3.5" branch is the default maven stream
for fedora. This means that everybody who "dnf install(s) maven" will
get maven 3.5, despite maven 3.6.1 being available as a non-modular
package in rawhide now. On the other hand, this was a major reason why
Ursa Whatever wasn't enabled for all default streams, because maven
from the 3.5 branch isn't able to build RPM packages. Yikes.

If I understand correctly, mizdebsk is working on making maven from
the modular branches be able to install in parallel with non-modular
maven packages, which would solve at least this particular issue with
maven. Still, I don't understand why modular branches for Java
packages are even necessary, and why it was necessary to force eclipse
maintainers to modularize eclipse as well. Sigh. At least for the
forseeable future, non-modular Java packages will stay maintained,
even if the Java SIG is basically nonexistent now.

Another issue is that the modular Java packages are now getting built
with OpenJDK 11, while the non-modular default is still OpenJDK 8, and
nobody is left to drive an OpenJDK 8 → 11 transition in fedora
forward. We're basically the only holdout on Java 8 still, with even
debian stable (!) defaulting to OpenJDK 11 now. This will probably
lead to all kinds of fun incompatiblities between modular (Java 11)
and non-modular (Java 8) packages. And I've not even mentioned the
myriad of other, slightly incompatible changes between modular and
non-modular Java packages ... *SIGH*

I hope this can give you some examples why actually, moving things to
default streams is making things worse for almost everybody, including
both packagers (of dependent packages), and users (who may get either
outdated, broken, or incompatible packages).

Now, I know that the "maven:3.5" and "ant:foo?" streams would not get
accepted as default streams today, because they conflict with
non-modular packages. But they still are defaults, and it's causing
problems.

Fabio

>  Perhaps this stuff is obvious to others already.  In RHEL8 while we
> have
>  certainly hit various problems with modularity at least I don't recall
>  my teams hitting major issues with default streams being available for
>  non-modular packages. 
Maybe the dogtag-pki team can offer some opinions here? I know that
they've had to deal with this on both RHEL and fedora.

Fabio

> Regards, Joe
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

[Alex Scheel]

----- Original Message -----
>  From: "Fabio Valentini" <decathorpe(a)gmail.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Friday, November 15, 2019 10:58:04 AM
>  Subject: Re: What are the benefits of default modular streams over non-modular packages?
>   
~snipping long thread~

>  Another issue is that the modular Java packages are now getting
> built
>  with OpenJDK 11, while the non-modular default is still OpenJDK 8, and
>  nobody is left to drive an OpenJDK 8 → 11 transition in fedora
>  forward. We're basically the only holdout on Java 8 still, with even
>  debian stable (!) defaulting to OpenJDK 11 now. This will probably
>  lead to all kinds of fun incompatiblities between modular (Java 11)
>  and non-modular (Java 8) packages. And I've not even mentioned the
>  myriad of other, slightly incompatible changes between modular and
>  non-modular Java packages ... *SIGH* 
I think, assuming the proper -target / -release flags are used in
all modular packages, this will largely be a non-issue. Java does its
best to allow building packages with newer JDK versions while still
allowing older JREs to run the code. That's not the case if -target and
-release flags are missing. It also only really affects the consumers
of Java _libraries_ built with JDK11. Almost nobody will notice if Maven
was built with JDK 11. However this issue has been discussed elsewhere,
and we've determined that we'll be fine (TM):

https://lists.fedoraproject.org/archives/list/[e-mail].o...

I do agree that we will need to migrate to JDK 11, but that'll take
time. Perhaps we need Miro's fine management skills and strict policy
enforcement to get us there a la python2->python3 migration.

>  > Perhaps this stuff is obvious to others already.  In RHEL8 while
> we have
>  > certainly hit various problems with modularity at least I don't recall
>  > my teams hitting major issues with default streams being available for
>  > non-modular packages.
>  
>  Maybe the dogtag-pki team can offer some opinions here? I know that
>  they've had to deal with this on both RHEL and fedora. 
Most of the RHCS team's perceived shortcomings of Modularity have come from
general issues, not ones stemming particularly from default streams. A
portion has probably been because we did this the wrong way and committed
to shipping it in RHEL before it was stabilized in Fedora. As has been
mentioned before on this list, we have some version of Ursa {Prime,Major}
in RHEL and we don't have large, conflicting efforts to maintain ursine build
trees in parallel to modular ones like Fedora has.

I've aired most of our opinions on this list in other threads. I don't think
it is worth reiterating here. But I will say we have much more leniency
when it comes to packaging there than we do here.

---

My personal opinion is that modules in Fedora are broken because of
politics and a lack of policy that exacerbates the technical problems.
Mostly that's because people are refusing to collaborate and work
together to solve problems, preferring to build their own silos. That'll
drive contributors away and vastly increase technical debt in the long run,
which we do really need to avoid to have a healthy community.


Default modular streams shadowing non-modular packages is one such
problem, especially when they ship libraries.


My 2c.

- Alex

[John M. Harris Jr]

On Friday, November 15, 2019 1:55:44 PM MST Alex Scheel wrote:
>  I do agree that we will need to migrate to JDK 11, but that'll
> take
>  time. Perhaps we need Miro's fine management skills and strict policy
>  enforcement to get us there a la python2->python3 migration. 
That's not the same, at all.

Python 2 and Python 3 are inherently incompatible, and many programs WILL NOT 
be migrated to Python 3. In fact, we're simply dropping many packages, some 
were even explicitly denied an exception, that refused to "upgrade" to Python 
3.

-- 
John M. Harris, Jr.
Splentity

[Kevin Kofler]

John M. Harris Jr wrote:
>  Python 2 and Python 3 are inherently incompatible, and many programs
> WILL
>  NOT be migrated to Python 3. In fact, we're simply dropping many packages,
>  some were even explicitly denied an exception, that refused to "upgrade"
>  to Python 3. 
Indeed. As much as I agree with Miro on the Modularity issue, his draconian 
Python 2 to 3 migration is not what I would call a good example to follow 
for such migrations. But this subthread no longer has anything to do with 
the subject of the thread, so can we please focus on the subject?

        Kevin Kofler

[Kevin Kofler]

Joe Orton wrote:
>  So it's clear to me that you see that packagers chosing default
> streams
>  over non-modular packages impose external costs on the rest of the
>  distro (packagers and/or users?) somehow.  This thread was supposed to
>  focus on benefits, and these vague claims about costs and trade-offs
>  seem speculative, but maybe you could expand on that a bit? 
Has this not already been mentioned in all the other threads?

Default streams:
* introduce upgrade path issues when upgrading to a newer Fedora,
* make it harder to replace packages with local versions (because the module
  normally takes precedence over non-modular versions of the same packages),
* may introduce dependency version conflicts due to versioned dependencies
  on other modules (whereas non-modular packages currently cannot depend on
  non-default modules, and it should really stay that way),
and those are just the 3 obvious issues.

Dealing with upgrade path issues and dependency version conflicts and using 
complicated workarounds to install local packages instead of the modular 
ones definitely comes at a cost (users' time).

        Kevin Kofler

[Petr Pisar]

On 2019-11-14, Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  I've asked whether it wouldn't be in fact much easier to keep
> the
>  default versions of our packages non-modular. 
[...]
>  Arguments were made that default modular streams are planned to
>  deliver the exact same experience as non-modular packages, yet it was
>  not said if it wouldn't be easier to just deliver non-modular packages
>  for default versions.
>
>  Maybe it would be helpful to try to reformulate the question:
>
>  **What are the benefits of default modular streams over non-modular
>  packages?** 
[...]
>  Considering we have 6 default modular streams, let me acknowledge
> that
>  for the maintainers who decided to deliver default modular streams
>  instead of non-modular packages, there clearly are some benefits.
>  While some of us might not understand them, let's not say there are
>  none. But even if there are clear benefits for the maintainers of
>  those modules, I'm asking about the benefits for everybody else.
>  
You answered yourself: "default modular streams are planned to deliver
the exact same experience as non-modular packages." If they provide the
same experience, they provide the same set of benefits. Hence there
cannot be any "benefits of default modular streams over non-modular
packages". Q.E.D.

If you want a disuccion, then you should not have stripped all
modularity features and than ask what are the benefits of modularity
without modularity.

-- Petr

[John M. Harris Jr]

On Friday, November 15, 2019 6:03:40 AM MST Petr Pisar wrote:
>  You answered yourself: "default modular streams are planned to
> deliver
>  the exact same experience as non-modular packages." If they provide the
>  same experience, they provide the same set of benefits. Hence there
>  cannot be any "benefits of default modular streams over non-modular
>  packages". Q.E.D.
>  
>  If you want a disuccion, then you should not have stripped all
>  modularity features and than ask what are the benefits of modularity
>  without modularity. 
I believe that was precisely Miro's point. If there are no inherent benefits 
to default modular streams, why should we have "default streams" instead of 
simply having non-modular packages?

-- 
John M. Harris, Jr.
Splentity

[Miro Hrončok]

On 15. 11. 19 14:03, Petr Pisar wrote:
>  On 2019-11-14, Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
> > I've asked whether it wouldn't be in fact much easier to keep the
> > default versions of our packages non-modular.
>  [...]
> > Arguments were made that default modular streams are planned to
> > deliver the exact same experience as non-modular packages, yet it was
> > not said if it wouldn't be easier to just deliver non-modular packages
> > for default versions.
> >
> > Maybe it would be helpful to try to reformulate the question:
> >
> > **What are the benefits of default modular streams over non-modular
> > packages?**
>  [...]
> > Considering we have 6 default modular streams, let me acknowledge that
> > for the maintainers who decided to deliver default modular streams
> > instead of non-modular packages, there clearly are some benefits.
> > While some of us might not understand them, let's not say there are
> > none. But even if there are clear benefits for the maintainers of
> > those modules, I'm asking about the benefits for everybody else.
> >
>  You answered yourself: "default modular streams are planned to deliver
>  the exact same experience as non-modular packages." If they provide the
>  same experience, they provide the same set of benefits. Hence there
>  cannot be any "benefits of default modular streams over non-modular
>  packages". Q.E.D. 
That is indeed how I understand it.

>  If you want a disuccion, then you should not have stripped all
>  modularity features and than ask what are the benefits of modularity
>  without modularity. 
What features have I stripped?

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Mikolaj Izdebski]

On Thu, Nov 14, 2019 at 4:59 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  I've asked whether it wouldn't be in fact much easier to keep
> the default
>  versions of our packages non-modular.
>
>  Others have said they are interested in this as well. A huge thread happened but
>  it hasn't delivered an answer.
>  Arguments were made that default modular streams are planned to deliver the
>  exact same experience as non-modular packages, yet it was not said if it
>  wouldn't be easier to just deliver non-modular packages for default versions.
>
>  Maybe it would be helpful to try to reformulate the question:
>
>
>  **What are the benefits of default modular streams over non-modular packages?** 
As Petr Pisar noted earlier, default streams are designed to deliver the same
user experience as ursine packages, therefore there is no *direct* advantage
or disadvantage of them over ursine packages, for Fedora *users*.

Default streams are modules. Building packages as modules has very significant
advantages to some package maintainers. Certain maintainers (like me) can save
a lot of time by building packages as modules.  This *indirectly*
benefits users and
other Fedora contributors - maintainers who can more easily build packages have
more time to spend on important bugs and features affecting users, can get more
involved in other Fedora activities etc.

--
Mikolaj Izdebski

[Kevin Kofler]

Mikolaj Izdebski wrote:
>  As Petr Pisar noted earlier, default streams are designed to deliver
> the
>  same user experience as ursine packages, therefore there is no *direct*
>  advantage or disadvantage of them over ursine packages, for Fedora
>  *users*. 
Sorry, the "no disadvantage" part is just not true:
https://lists.fedoraproject.org/archives/list/[e-mail].o...

The design fails to deliver on its promise of delivering the exact same user 
experience.

        Kevin Kofler

[Stephen Gallagher]

On Mon, Nov 18, 2019 at 7:24 AM Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Mikolaj Izdebski wrote:
>  > As Petr Pisar noted earlier, default streams are designed to deliver the
>  > same user experience as ursine packages, therefore there is no *direct*
>  > advantage or disadvantage of them over ursine packages, for Fedora
>  > *users*.
>
>  Sorry, the "no disadvantage" part is just not true:
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  
>  * introduce upgrade path issues when upgrading to a newer Fedora,
This has been acknowledged as a bug and is on its way to being fixed.

>  * make it harder to replace packages with local versions (because the
> module normally takes precedence over non-modular versions of the same packages), 
This is a valid concern and it is one we are investigating a solution
for right now. One possible answer: if the RPM location is specified
directly (URL or filesystem location) assume that the user wants to
override the modular package.

>  * may introduce dependency version conflicts due to versioned
> dependencies on other modules (whereas non-modular packages currently cannot depend on
> non-default modules, and it should really stay that way), and those are just the 3 obvious
> issues. 
We just adopted the policy that a default module stream may not depend
on any non-default module streams. As long as this is properly
enforced, this issue is addressed already.

>  The design fails to deliver on its promise of delivering the exact
> same user
>  experience.
>  
This is incorrect. The *implementation* is currently failing to
deliver the same user experience.

[Nico Kadel-Garcia]

On Mon, Nov 18, 2019 at 6:23 AM Mikolaj Izdebski <mizdebsk(a)redhat.com&gt; wrote:
>  On Thu, Nov 14, 2019 at 4:59 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  > I've asked whether it wouldn't be in fact much easier to keep the default
>  > versions of our packages non-modular.
>  >
>  > Others have said they are interested in this as well. A huge thread happened but
>  > it hasn't delivered an answer.
>  > Arguments were made that default modular streams are planned to deliver the
>  > exact same experience as non-modular packages, yet it was not said if it
>  > wouldn't be easier to just deliver non-modular packages for default versions.
>  >
>  > Maybe it would be helpful to try to reformulate the question:
>  >
>  >
>  > **What are the benefits of default modular streams over non-modular packages?**
>
>  As Petr Pisar noted earlier, default streams are designed to deliver the same
>  user experience as ursine packages, therefore there is no *direct* advantage
>  or disadvantage of them over ursine packages, for Fedora *users*. 
Confusing and inconsistent resolution of dependency chains is a direct
consequence of using modularity. These threads have pointed out
others.

>  Default streams are modules. Building packages as modules has very
> significant
>  advantages to some package maintainers. Certain maintainers (like me) can save
>  a lot of time by building packages as modules.  This *indirectly*
>  benefits users and 
Those maintainers are a small though vocal minority. Can anyone name
three packages that genuinely benefit from modularity, rather than
/etc/alternatives, SCL style separate deployment in /opt/. If there
was always a bae installation and modules were, in fact, only an
add-on, that might have been more stable.

>  other Fedora contributors - maintainers who can more easily build
> packages have
>  more time to spend on important bugs and features affecting users, can get more
>  involved in other Fedora activities etc. 
At the cost of the time of *other* package maintainers who have to
deal with the inconsistent dependency resolutions at build and
deployment time. It's not, so far, proven to be a helpful technology.