Why is this not going to FESCo?

@bex Because the original naming request (prefixing EPEL stream names) came from the FPL. We're trying to learn the reasons for it, so we can determine if the additional engineering effort is sensible.

For a little more context:
Right now, if EPEL is permitted to use the same stream names as Fedora (in other words, things like nodejs:12 as opposed to nodejs:epel-12), then it becomes very easy for packagers to build for EPEL. Specifically, the existing Module Stream Expansion functionality will just go ahead and start building for EPEL 8 once that platform appears in the PDC database. And, in most cases, it will build just fine. This also moves us from an opt-in to maintaining EPEL packages to an opt-out to maintain EPEL Modules.

There are some downsides to this: we need to have tooling and policies in place to address what happens if RHEL releases a module stream of the same name. @psabata and I generally agree that we should treat this much the same way as with non-modular packages, which is to say that RHEL would take over ownership of the stream (dealing with the version number appropriately so that upgrades are trivial).

Forcing EPEL packages to use a namespaced stream has other advantages and disadvantages. The obvious advantage is that it's very clear to the user when they have selected an EPEL stream (thus cutting down on support calls to Red Hat about EPEL content). However, this comes with considerable disadvantages:

• Module Stream Expansion won't work because it creates all of its builds with the same stream name. Writing specialized code to detect builds for EPEL 8 and change this mid-flight would be complicated and error-prone. (Particularly in the straw-man case of a module that's build once, run anywhere because it's statically linked, like the rust packages.)
• If the stream has dependencies on another module stream (e.g. meson depends on ninja), then all of those stream names need to be adapted to include the EPEL prefix as well. This is, again, probably doable, but it's a considerable amount of work with no guarantees that it will succeed.
• If we want to do this anyway, without making changes to Module Stream Expansion, it means that the module becomes an entirely separate stream in dist-git that is maintained separately. That gets us back to opting-in to EPEL 8, rather than opting out. We'll end up with less content in that case.

I think it's fairly clear that I'd prefer to take the option of not prefixing the stream names in EPEL, but as this is partly a marketing and perception question, I think we need the Council to weigh in.

I encourage us to do one of two things:

a) Let @mattdm explain his concerns here
b) Open a FESCo ticket where @mattdm can be part of the conversation.

Regardless, assigning this one to @mattdm

I'm trying to remember what I was thinking. :)

I have the sneaking suspicion that the idea for namespacing the streams was for package streams, before the concept of modules having their own namespaces was even a thing.