On Thu, 6 Aug 2020 16:45:15 +0200 Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > 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/ I agree. > 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 This make the policy less clear than it needs to be. It spends too much time talking about non-ELN Fedora and not enough time getting into the ELN specifics. This wording also seems like a way to sneak in modularity through the back door. I know it explicitly says it isn't, but it still smells bad. If this experiment goes ahead and proves successful, then I expect there will be lesson learned and the policy will be changed before it is adopted for Fedora releases. Surely, writing the policy for Fedora in general can wait until after some ELN experience is gained. > 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 do not recall any discussion from the modularity advocates of any design level issues, nor of any proposals to address them. I do not believe that any changes in the technology are forthcoming. Indeed the need for such changes does not even seem to be acknowledged. > 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/ I anticipate great consternation in the CentOS and EPEL user communities when RHEL decides to change some default modules. It is my impression that modularity has caused problems for the CentOS and EPEL developers: <https://lists.centos.org/pipermail/centos/2020-August/351261.html> These problems have delayed the delivery of CentOS 8 and EPEL 8 and leave a poor impression of the quality of RHEL 8. Maybe some RHEL customers are wildly enthusiastic about modularity, but I don't see it in the CentOS community. > 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? +1. From here ELN looks pretty closed. So does modularity. > 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. Many of the modularity problems manifest themselves at Fedora version upgrades. I do not see how default modules in ELN will fix this. Also, ELN does not provide an installer, limiting the availability of ELN and the usefulness of this testing. If ELN were a viable alternative to rawhide and used in the wild, then this testing could receive actual user feedback. The many FESCO tickets were the result of user experience. > 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 too find that the proposal fails to describe the relation between rawhide and ELN. There's no way this proposal should be approved unless the gap is closed. I would like to see the policy require synchronization between rawhide and ELN and that tooling to enforce this policy be in place as prerequisite. > 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? How does ELN accomplish the state of being not a fork and different at the same time? How does this affect the rest of Fedora? If it doesn't, then why is ELN part of Fedora? If it does, what is the affect and where is it described? > 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. > 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. ELN is a Fedora project. Thus I ask: How do default modules in ELN benefit me, a developer who uses Fedora as my platform of choice? How do they benefit other members of the Fedora community? The Benefit to Fedora reads: <https://fedoraproject.org/wiki/Changes/ModularPolicy#Benefit_to_Fedora> This policy makes explicit what packagers can and cannot do with Modules in Fedora, which should avoid future issues like those that were seen during the Fedora 31 and Fedora 32 cycles. This sounds like damage control. It does not describe in any way how adopting this change would be an improvement! I think this is bogus and disrespectful. Please describe some real benefits over the status quo. This proposal should be rejected unless positive and concrete answers are provided. Where's the "How to test" section for <https://fedoraproject.org/wiki/Changes/ModularPolicy>? One of the stated objective is that this is a test bed for default modules in Fedora. I believe that modularity in Fedora has deep and fundamental design problems. I believe that a policy band-aid is not a solution to these problems. I am glad that FESCO acted to limit modularity and encourage FESCO to proceed with caution and due diligence. My experience is that modularity was hyped with generalities and few specifics and yet managed to fall short of expectations. I find that, even after all these years, end-user and general developer documentation for modularity is sorely lacking. I am disappointed that responsibility for modularity maintenance was moved to another team while there were major outstanding design problems and that the new team does not seem to have the remit to fix these problems. FESCO, this proposal is inadequate. It does not provide any benefit to Fedora, it does not describe the relation between rawhide and ELN, and it seems to be over-reaching an a way that leaves a bad taste in my mouth. Please reject it. Jim _______________________________________________ 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
