On Tue, Jun 23, 2020 at 7:36 AM Miro Hrončok <mhron...@redhat.com> wrote: > > On 23. 06. 20 13:29, Josh Boyer wrote: > >> (It*may* be possible to automatize this, but not as easily as with > >> singular packages. And considering that non-modularized packages > >> need to be handled too, there will be at least two paths.) > >> > >> - (hypothetically) if we have default modules in eln, and work is done > >> in those modules and skipping rawhide (for example by not building the > >> packages in rawhide), we have an unpleasant situation where eln and > >> rawhide diverge. > > This is a very tenuous strawman. You could also run into a case where > > ELN forbids modules or default module streams and the maintainers > > simply choose not to maintain anything in Fedora at all. That's far > > worse than divergence in my opinion. > > When ELN was proposed and discussed, separate eln branches were proposed by > several Fedora and RHEL maintainers. It was dismissed, and it was said > repeatedly that rawhide/ELN divergence MUST be avoided. I wonder if that > requirement has changed.
Divergence where? At the source level? Why would the existence of a default module in ELN cause divergence at the source level? It wouldn't. The rawhide sources would be used for the module build in ELN. If you mean at the binary level, then I have no idea how anyone possibly thinks ELN and Rawhide are the same because ELN is built with entirely different flags, settings, etc. > > Fortunately, I think neither are > > actually likely and this part of the conversation seems like it's > > pointless to debate. > > This has happened in the past when Fedora had default modular streams. Whether > likely or not to repeat, we have experience with the problem, so the > discussion > is not pointless at all. You seem to be concerned less about divergence and more about abandonment of packages in Fedora, at least in ways counter to how the default distribution is built. You could come up with some guidelines on usage of ELN modules that require existing content to be maintained as it is in Fedora if that's what you want to ensure. It's onerous and causes extra work, but allows people to do their work in the open. However, if you prevent that from happening entirely, you run the risk of them abandoning the packages entirely which is counter to your goal (I think). josh _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
