On Mon, Jun 22, 2020 at 03:36:30PM -0400, Josh Boyer wrote: > On Mon, Jun 22, 2020 at 1:27 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > > > On 18. 06. 20 21:22, Josh Boyer wrote: > > > The introduction > > > of default module streams was a direct result of wanting to help > > > customers that are used to running 'yum install mariadb' still be able > > > to do that. > > > > Hello Josh. > > > > I'd like to ask whether RHEL 9 has decided for default modular streams despite > > their failure in Fedora, whether this decision is final and what was the > > reasoning behind it. Hi Josh, Miro, I think there has been a misunderstanding. I'm pretty sure Miro's question is about "default modules" not "default streams" (i.e. "modules enabled by default" vs. "the stream of a module to use when a different one is not explicitly selected"). Default streams are not subject of much discussion. There is no plan to limit them either in Fedora or ELN. But from your reply it is not clear which of those you have in mind. Let's please clarify what we're talking about first... Zbyszek > That's an interesting question. I think for the purposes of this > discussion, we should acknowledge that usage of default module streams > in Fedora and usage in RHEL aren't equivalent. Therefore, failure of > adoption in Fedora doesn't necessarily equate to failure in RHEL. > With that context, I'll continue. > > > When discussing default modular streams in ELN, we have heard that ELN needs > > default streams because RHEL 9 needs them. I would like to know if this > > information is something that comes from RHEL leadership directly or whether it > > is a personal option of the people who said such things. > > Why does it matter if "RHEL leadership" said it, or if a RHEL package > maintainer said it? Politely, I find that an odd way to frame that > discussion, devalues individual team autonomy, and ignores what the > conversation points should be. Let me suggest a different way. > > 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. > > 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. > > 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 _______________________________________________ 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
