On Tue, Jun 23, 2020 at 5:14 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > On Mon, Jun 22, 2020 at 03:36:30PM -0400, Josh Boyer wrote: > > We know within RHEL we have teams that will likely continue using > > default streams. We also know that some teams will not. Further we > > know that somes teams will likely not use modules at all, just as > > teams in RHEL 8 did not use modules. The flexibility to choose the > > approach that makes the most sense for that team and their package set > > would be what I would hope we try to enable in Fedora and ELN. It is > > fair to ask why a team would want to continue using default streams, > > and I can offer guesses but they would be only that. I would hope > > such teams could freely chime in here. The point is, within RHEL it > > is actually their choice to make, balancing the needs of their > > customers with the content they are packaging, etc. > > [After clearing up my misunderstanding about terminology in the other subthread:] > > The choice of allowing "default module streams" is not a choice that > should be taken lightly on the level of individual contributors / > teams, because it impacts the way other teams build *their* packages > and/or modules. In particular, if "enabled", other maintainers need > to remain aware of modules and need to take the quirks of modularity > into account when working on their packages. And past history shows that > demodularization (i.e. switching of modular content back to non-modular > rpms) is surprisingly complex, so the decision to "enable" cannot be > undone easily. Thus the discussion we're having now about the choices > for ELN. Agreed. > > It remains unclear to me why Fedora would go out of its way to > > disallow usage of default streams in ELN. I understand they can > > present some issues if used incorrectly, or for something that is core > > to non-modular content, but the concept of a default stream being > > forbidden outright is strange. Default streams in ELN don't impact > > the wider Fedora distribution and removing them eliminates options and > > flexibility, forcing their usage to become a downstream-only concept > > which is exactly what we're trying to avoid with ELN to begin with. > > Default streams in ELN definitely impact how RH packagers work with > ELN and rawhide. Roughly: > - if we have no default modules in rawhide or eln, work done in rawhide > translates 1:1 to eln and it seems likely packages can be just automatically > rebuilt for eln. > > - if we have default modules in eln, and work is done first in rawhide, > then additional work is required to adapt the modules in eln. If Fedora forbids default modules in ELN, then they'll have to do additional work downstream in RHEL if that is the best choice there. That is also bad. > (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. Fortunately, I think neither are actually likely and this part of the conversation seems like it's pointless to debate. > Since the first scenario seems the most straightforward and pleasant for > everyone involved, it is imho a good question whether there are technical > reasons to follow the second option. And maybe that is the option most will choose. However, not even letting ELN have the option seems to preclude that choice entirely. josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
