On Thu, Aug 6, 2020, at 10:45 AM, Miro Hrončok wrote: > On 05. 08. 20 21:36, Stephen Gallagher wrote: > > FESCo has requested that I submit the module policy once more to the > > Fedora development list for discussion. Feedback is welcome. > > > > == Requirements for Default Streams > > * Default streams are not permitted in Fedora or EPEL 8. Fedora ELN > > permits defaults streams that adhere to the policy below. > > Since this has been discussed at lengths at FESCo and this is the first time it > has been brought here (thanks for doing it, Stephen), let me summarize my > concerns with allowing default modular streams in ELN. > > I would like to know if my concerns are valid or if I am just biased. Sorry for > the long email. > The concerns sound valid to me. Despite the concerns, it sounds like the decision has been made to have Default Streams in RHEL Next, so we should develop an appropriate policy for them in ELN. Let's not impede RHEL development unnecessarily, but let's work to make RHEL better. Part of that might be convincing the powers-that-be to give up default streams, but the topic that started this thread is "what is the policy, assuming they've already been allowed." > > Fedora has experimented with default modular streams for several > releases and we > seemed to be at an agreement that the experiment has failed: > > See https://pagure.io/fesco/issue/2406 which includes links to relevant > previous > discussions on the topic. Admitting that default modular streams are > bad took as > nearly two years, despite a few loud and persistent individuals > pointing it out > since the beginning. > > While I understand the original idea behind the concept of default modular > streams concept, shipping defaults via non-modular content has been proven > superior to default modular streams -- it has been proven that default modular > streams cannot be better than nonmodular defaults and that they can only try to > be as good as them, while they are currently technologically failing to do that: > > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/D2LQ6C6FHDS2LMKPDGCLFJDNHAPA6Q2B/ > > > The currently proposed modularity objective for Fedora admits that this > won't be > fixed until ta least Fedora 35 and later: > > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/RF4GUWFIDIASBDKS2RUVDHTSAWCMCWL4/ > > The current modularity tech-lead strongly discourages default modular streams: > > https://pagure.io/fedora-docs/modularity/pull-request/83#comment-122310 > https://pagure.io/fedora-docs/modularity/pull-request/83#comment-122502 > > > Yet despite all this, we got a proposal to allow default modular streams in ELN. > The messaging about this proposal suggests that later, default modular streams > might be proposed for Fedora as well. > > > """At present, these rules will apply only to Fedora ELN, but are written in > such a way as to be reusable for Fedora and EPEL in the future through another > Change Proposal.""" -- https://fedoraproject.org/wiki/Changes/ModularPolicy > > > Fedora has decided that default modular streams are no-go. While I > admit that > such a decision can be reverted at any time based on significant > changes in the > technology, such changes have not happened and are not planned. Yet > strong > supporters of default modular streams try to allow them again and > again, despite > the enormous amount of feedback they've received including the feedback > from the > current modularity team and tech lead. > > > I sincerely don't understand the RHEL's need for default modular streams, but > when I tried to query the motivation behind this, the answers haven't made it > any better: > > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/YIUXL2AWY3GKITU4TBUSKL2IUHDUPB26/ > > The idea that we let the maintainers decide how they want to ship the default > content is exactly what failed in Fedora in the first place. But if RHEL people > feel strongly that we need default modular steams to succeed, so be it. What I > don't understand is why do we need this in Fedora (ELN). It boils down to this: > Is ELN part of Fedora and should it follow Fedora's feedback and Fedora's > opinions, or is it a RHEL project executed in the open, with decisions made > behind closed doors? > > I've heard several times that we need to have default modular streams in Fedora > ELN to have a place to test them. In my opinion, we had this place, it was in > Fedora, we have tested them and they failed. Hence I don't understand what's > more there to test. > > OTOH, why don't just let the ELN SIG do this if it doesn't affect > "Fedora > proper"? Because I think it does. Since the beginning of the ELN > project, it has > been said that it ships Fedora rawhide content, built differently. Yet > if we > ship the default modular streams content in Fedora ELN and the > nonmodular > defaults in Fedora Rawhide, suddenly we ship different things, unless > we have > technical means to ensure the content is synchronized. > I'd propose that any default module stream in ELN should have its packages built only from the "master" branch in dist-git, and should not have any separate branch. This is the item that I did not see in the proposed policy, and a necessary addition, in my opinion. Perhaps with an exception process for software that requires older bulid deps, but even in that case, they should be added as compat packages if at all possible. > When the ELN proposal was discussed, several package maintainers (both from > Fedora and RHEL) proposed to have an eln branch. It received a big NO because > the content would diverge and keeping it in sync would be (close to) impossible. > > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/44MCFHOFORTPNJFGK6JJ6YMAHFUT7QG3/ > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/WRJNM7I5TFQ5TEBOUKKH757K5ME3I47F/ > ..and many times more... > > Fedora ELN should not be a fork. Yet (some of the) default content of > Fedora ELN > would be built from modules, which packages built from different > branches. > Has the objective been changed? Is having separate branches for Fedora > and > Fedora ELN no longer a big NO? What changed? > > I am worried about the divergence between Fedora and Fedora ELN. I am > worried > about certain maintainers only maintaining their modules without > upgrading > packages in rawhide -- and a need of a large volunteer-driven effort to > backport > improvements and fixes from modules to nonmodular packages: From Fedora > ELN to > Fedora. This seems wrong to me, as I've always considered Fedora to be > the > upstream of RHEL (and by extension of Fedora ELN) rather than > downstream. > Similarly, I'd argue that ELN shouldn't have default content that isn't also available by default in Fedora. this would likely be solved by my suggestion above for default modules to use only the master branch. > When I expressed this concern in the "RHEL 9 and modularity" thread, > the > discussion went nowhere: > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/PQX75DGRIICQLG5KBOY4HTOFFYZVWP6K/ > (and replies) > > > I believe that allowing default modular streams in any Fedora project > is a bad > thing to do before the technology sees large design-level changes. I > believe > that RHEL completely ignoring Fedora's feedback is a very sad thing to > happen. I > believe that having default modular streams in ELN will negatively > affect > general Fedora packagers. But I realize that this is juts one person's > opinion. > At FESCo, I try to represent the opinion of Fedora package maintainers, > not just > my own. Hence I am sharing my concerns here to hear feedback from > others. > I appreciate your efforts here! Thanks for raising the concerns. They echo my own. V/r, James Cassell _______________________________________________ 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
