On Thu, Aug 6, 2020 at 10:46 AM Miro Hrončok <mhroncok@xxxxxxxxxx> 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. > > > 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 > Those comments were from Daniel when talking about Fedora as it exists today. Not about ELN. Yes, he discourages their use in Fedora. However, ELN has a mission to be a bridge to future RHEL and that distribution has committed to default streams as a business necessity for multiple reasons (among them support lifecycle which is much harder to address via non-modular content). > > 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. > It was written that way *at your request*. You specifically asked for a proposal for "Fedora" that we could initially apply only to "Fedora ELN". It seems disingenuous to now use that as an argument against it. > > """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/ > Josh listed some of the key reasons behind default streams: that enterprise customers don't like to learn new commands. So default streams allowed us to package content with shorter-than-RHEL-lifetime and still `yum install foo` would install something the customer could use. > 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. I agree with this statement, hence why the policy expressly requires "Changes to default streams *MUST* be approved via a Change Proposal". This means that the maintainer must get FESCo approval to become a default stream. > 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? Decisions will not be made behind closed doors, but Red Hat *will* have a strong opinion on them. And if ELN diverges too far from Red Hat's needs, the experiment of ELN will have failed. Red Hat is committed to making its reasons for such needs as transparent as possible, so claims of "decisions behind closed doors" are rather alarmist. That said, I cannot deny that there is a crucial balance to be struck here and that, I think, is one of the key pieces that default streams can help with. As I have said elsewhere in this email (I'm jumping around while writing, so I think this part is below): ELN will *always* be built from sources that are available for Rawhide to deliver. In effect, it will be equivalent to installing Rawhide with that module stream enabled in the kickstart. In cases where Red Hat strongly believes that a particular alternative stream in Rawhide is more in line with the needs of RHEL, a Change Proposal will be filed with a request to have that stream become the default in ELN. > > 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. Because software never changes or improves over time. Right, I forgot we gave up on Python after we discovered that its unicode handling wasn't great... Honestly, I don't understand your argument here. The *implementation* had issues. Those issues have been identified and plans exist to resolve them. We agreed not to put that in Fedora until we could prove it was fixed. > 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'm... not really sure what you're comparing here, but I'll try to make it clearer. * Anything that exists as non-modular content in ELN will have been built from the Rawhide branch of the same non-modular RPM. * The set of non-modular packages built in ELN will be a subset of the non-modular packages in Rawhide * Module streams built for Fedora Rawhide *may* also be built for Fedora ELN. * Module streams built for Fedora ELN *may* be set as the default stream in ELN. If so, those RPMs coming from the default stream *must not* overlap the non-modular content. Does that make more sense? > 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? See the previous statement. The module streams for ELN will be built from the exact same YAML as the equivalent Rawhide module stream. Thus what is being delivered is still "Rawhide content", it just happens to differ about which is the *default content*. > 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 I feel that this is highly unlikely since ELN won't be a deliverable in the traditional sense of the term. If they were to do this, their package would stagnate in Fedora. If that happens, that's what the non-responsive maintainer process is for. > -- 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. I guess we haven't been clear enough about the artifacts that ELN produces. They are intended as a compose for testing/CI purposes *only*. We will not be mirroring them or making them publicly visible on getfedora.org or anything of the sort. It's a bootstrapping effort towards RHEL X+1. I intend to make it VERY clear that working in ELN but not maintaining that content in the rest of Fedora is unacceptable. That's part of the reason behind the package comaintainership requirement in this policy. > 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 understand your stance on the matter at large. I hope that my responses above have provided you with at least some measure of improved clarity. _______________________________________________ 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
