To be clear, I am reading every single reply to this thread very carefully. We *will* be taking all of this feedback into consideration, but please understand that we're also trying to balance things. As Neal noted upthread, we do have a responsibility to our downstream to make sure that we do not break the ability to manage default streams. This becomes much more difficult if we cannot have them in Fedora, because the testing of them is lost. Additionally, no one on the WG disagrees with you that the current state of things is undesirable. I take a moderate amount of offense to the repeated insinuations that the solutions we are building are "hacks". Yes, there's a proposal to work around the upgrade issue to F31 that is absolutely a one-off hack to buy time. But our plans for how upgrades should work long-term as well as how defaults need to behave in the distro are being considered very carefully. We are trying to avoid breakage and to make the process simpler, but we are also shoring up the bridge while crossing it.

We are absolutely considering the option of disallowing default streams in Fedora, but we *really* don't want to rush into that. For one thing, we do have a number of packages that have moved to modules-only that would have to convert back. For some projects, this is probably just an annoyance, but for others this may be a major impediment. In particular, one of the advantages of Modularity is the ability to have buildroot-only packages that are different from the base operating system (and don't end up delivered as artifacts from the module). There are likely modules out there that rely on this behavior because their build requires a newer or older version of some package than the non-modular buildroot provides. This is not the sole problem to address if we go the "no defaults" route, just the first that came to mind. It's unclear to me right now if forcing everyone back to the old behavior is less effort than fixing the remaining Modularity issues. And since we need to fix them for RHEL as well anyway, it's worth considering carefully if the added work is worthwhile.

I'm wary of assuming that this thread represents the whole of Fedoran opinions, however. As we all know, it's generally the set of people who are upset that speak up the loudest. I'm not discounting your concerns (far from it!), but if we only base development decisions on "make sure no one is upset about it", we'd never accomplish anything new at all. This is why when I've been sending out these emails to discuss ideas, I've been trying to carefully describe both the use-cases and the technical limitations (both intrinsic to the design and those that are the result of imperfect implementation) each time. It's somewhat disheartening to hear responses that largely boil down to "If you can't get it perfectly right, stop trying!".