I still haven't heard back about https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JX7CNMIYVWBY4PWV3QQIDQGOTSNQJB5D/

Anyway, given the above, and this:

https://pagure.io/fesco/issue/2003#comment-607196

And this:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JJ67QWPFS6T3MFPTCFEJ6RWAVWLI5ZJZ/ and that entire thread basically and also the other 2 threads.

I must vote -1. Allowing nonmodular packages to buildrequire modular packages in any form in the current state of our tools, design a packages, is a dangerous path. Enabling this would be a disservice to our community.

I agree with Miro, -1 as well.

-1

+1 - while there are certainly some issues with module default streams that still need to be ironed out, default module streams are something that we already have in Fedora, and the equivalence "default module stream <=> ursine buildroot" seems both necessary and natural.

I don't think there were any issues in devel thread that weren't answered. It might be good if some of the answers got fed back into the change proposal.

Here are my top reasons to vote -1:

1. Nowhere in the thread it was said why are default modules better for our users than keeping the default version as ursine package, it was always described as "ideally the same, but there are issues" or as a benefit for the modular packagers. There might be benefits for the "modular packagers" but it doesn't outweigh the issues.
2. The proposal doesn't say at all how the change will technically work and what happens with conflicts between ursine packages and default modular packages.
3. if we enable this, all Java packages become FTBFS. Java has been "broken" for a while, and this was supposed to "unbreak" it, but in fact it will make the situation worse.
4. if we admit that there are issues, I believe we need to iron them out before enabling modules in buildroot. Not enable them first and then wait for them to be ironed out without any deadlines.

Ursa Major was rejected earlier by FESCo, and Ursa Prime (the heart of this proposal) was conceived and coordinated with numerous other people to have a more agreeable solution for Fedora. To now turn that down as well seems like moving the goal posts unfairly.

On a more philosophical note, it's OK for there still to be some issues to iron out in a relatively new technology. This is an iterable concept for which Fedora is designed and intended.

To now turn that down as well seems like moving the goal posts unfairly.

It was discussed via https://pagure.io/fesco/issue/2003 and never agreed upon.

Either way accepting such a big change on the idea that it would be unfair not to do so would be... well, unfair to our users and our community.

As requested, I've put together a document (with help from @churchyard) describing what would be required to drop default streams in Fedora 32.

I've also sent FESCo members a link directly to allow them to comment on the document directly. The link in this comment is public and can be viewed by anyone. (It should auto-update with any edits we make.)

Ugh, that link doesn't work outside Red Hat... let me see what I can do about that. Please hold.

Let's try attaching an exported PDF.

Is there any idea from dnf maintainers (who I assume would have to work to make any of those things happen on upgrades) how long they might take? ie, longer than until f32beta?

I'm commenting the idea of dropping the defaults:

If you decide to drop the defaults from the distro, they will simple stop working, no dnf change is needed.

My personal opinion is that by dropping the defaults you'll make Fedora user unfriendly.
Users will have to enable streams by hand if they want to install some packages. That's currently not possible using Gnome Software, they'll have to use DNF. It also looks that the stream upgrades will become a problem of the end users. I'd expect that all streams we ship in Fedora N have clear transition to Fedora N+1.

There should be a concept of stream life cycles including dropping a stream or obsoleting a stream with another. Everything else is merely a workaround.

I'm commenting the idea of dropping the defaults:
If you decide to drop the defaults from the distro, they will simple stop working, no dnf change is needed.
My personal opinion is that by dropping the defaults you'll make Fedora user unfriendly.
Users will have to enable streams by hand if they want to install some packages. That's currently not possible using Gnome Software, they'll have to use DNF. It also looks that the stream upgrades will become a problem of the end users. I'd expect that all streams we ship in Fedora N have clear transition to Fedora N+1.
There should be a concept of stream life cycles including dropping a stream or obsoleting a stream with another. Everything else is merely a workaround.

@dmach
I don't disagree with anything you've said, but the concern FESCo has is that because the lifecycle stuff hasn't been sorted out yet, we should temporarily stop using default streams in Fedora. We can ask to restore them later once we have figured out the upgrade/obsolete problems. So we're looking to see what it would take to back the default streams out for now.

My personal opinion is that by dropping the defaults you'll make Fedora user unfriendly.
Users will have to enable streams by hand if they want to install some packages.

Not if the defaults are in non-modular Fedora, which is what I have always advocated for.

• AGREED: Ursa Prime in rawhide with the remark that it doesn't expose
  everything, not even "default everything" but rather exposes only
  vetted list of modules (+5,0,-3) (jforbes, 16:21:28)
• AGREED: For the purposes of testing, we will allow the avocado and
  dwm modules in the Ursa Prime buildroot (+5,0,-3) (jforbes,
  16:30:38)

AGREED: Ursa Prime in rawhide with the remark that it doesn't expose
everything, not even "default everything" but rather exposes only
vetted list of modules (+5,0,-3) (jforbes, 16:21:28)
AGREED: For the purposes of testing, we will allow the avocado and
dwm modules in the Ursa Prime buildroot (+5,0,-3) (jforbes,
16:30:38)

See https://pagure.io/releng/fedora-module-defaults/pull-request/184

I added overrides for the ant, gimp, maven and scala modules to drop their default stream from the buildroot.

AGREED: Ursa Prime in rawhide with the remark that it doesn't expose
everything, not even "default everything" but rather exposes only
vetted list of modules (+5,0,-3) (jforbes, 16:21:28)
AGREED: For the purposes of testing, we will allow the avocado and
dwm modules in the Ursa Prime buildroot (+5,0,-3) (jforbes,
16:30:38)

For my understanding, should this be interpreted as "change accepted" or "decision deferred until we see the results of this test"?

This effectively means "change accepted". Only two modules are authorized, but if more are to be authorized, it would be better to open a new ticket. Let's close this.