On Wed, May 13, 2020 at 8:04 AM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > On Wed, May 13, 2020 at 6:56 AM Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: > > I have several reasons against ELN, which I have already stated for past > > versions of your proposal (Should I really have repeated those at every > > single revised version that you came up with to bypass the repeated > > rejection?): > > * Having a buildroot that drops support for some subarchitectures is a step > > towards dropping those subarchitectures for everyone, which is exactly > > what we do not want. There is absolutely no reason to test dropping > > subarchitectures anywhere if we are not going to deploy it ever. > > FWIW, we do not currently have that in place (and may never). That > said, I disagree with your ex post facto statement that we would never > drop any subarchitectures. We certainly wouldn't drop them without > sufficient information to justify it, which is why we would need a > place to learn that information. > > That said, the AVX2 proposal is currently on hold and is (IMHO) > unlikely to be implemented for RHEL 9. > > > * Having a buildroot called "EL Next" means that Fedora gets in the business > > of composing the development version of RHEL in addition to the > > development version of Fedora. I do not see how this is the job of Fedora > > and Fedora maintainers. RHEL should be developed on RHEL infrastructure, > > by RHEL maintainers only. > > That sounds like the exact opposite of open source, to me. The entire > point of this exercise is to do *less* work out of the public eye. The > set of people who would be doing this work behind the firewall are now > going to be instructed to work in Rawhide (and, by extension, ELN) to > prepare for future versions of RHEL. This will also give the community > at large more opportunity to influence the eventual RHEL 9 (and > onwards) content and design. > > So, new issues that are discovered while building for a RHEL prototype > will be far more visible and can be addressed earlier, either by the > community maintainer or the RHEL maintainer working in the Fedora > environment. > I want to preface this first with the statement that I think having ELN is a good thing in general. I would actually really like to see RHEL development just be an aspect of Fedora, and I would *love* for other Fedora downstreams to do the same within Fedora. Excluding commercial downstream users of Fedora (which isn't just Red Hat!) is a great way to completely destroy our community. I'd love to see Amazon Linux development in Fedora, for example. And non-commercial side-stream/down-stream consumers and contributors like Mageia, OpenMandriva, etc. I would love to see folks from SUSE involved in Fedora too, just as I would love to see Fedorans involved in openSUSE. I want all of us in the RPM Linux distribution ecosystem working together more to solve problems better! But I think a huge part of the reaction about ELN comes back to this perception by folks that Fedora is not useful on its own and only exists as an alpha/beta test bed for RHEL. In recent years, it has increasingly appeared like this was true (wrt modularity, ARK, and recent CPE stuff). It's *generally* not, but there are definitely some folks I've met within Red Hat who *do* consider it that way, even though it's absolutely wrong. I've even heard grumbles from folks who wished it Fedora worked like CentOS (which is only a user community and not a developer+user community). And it doesn't help that Fedora is technically the outlier among Red Hat projects: no other Red Hat project has a governance model like Fedora's. No other Red Hat project has formal structures to allow the community to have as strong of a voice as it does. A lot of Red Hat projects are in fact set up the *opposite* way: there is no way for the community to have a strong influence without getting a Red Hat employee to be on their side. It's quite interesting, because if you look at projects like Kubernetes that are very successful, they are structured very similarly to how Fedora is. Many of the concepts and governance structures are extremely similar to how the Fedora Project works. The difference between Fedora and Kubernetes is that Fedora doesn't have people paid to advocate for the community and encourage folks to participate in it. When *I* look at Fedora, I see something special: a community with massively unrealized potential. We're a huge passionate group of folks that try to work diligently and amicably with the communities that make the projects that the Fedora Linux distribution ships. We are also often the drivers of innovation. In many cases, this is obvious (UsrMerge, systemd, PipeWire, Wayland, EarlyOOM, etc.). In some cases, it's not (Koji, fedmsg, HyperKitty, Pagure, Dist-Git, Ansible, AppStream, RPM-OSTree, etc.). And a great deal of this is driven by people in the community who *aren't* from Red Hat! But a lot of people don't see it this way, and many of us bristle when they bring up the RHEL point. Just look at Phoronix, Reddit, or any other place, and you'll see the comments about people being "free labor" or "free QA" for Red Hat. This is an unfair characterization that speaks to a deep misunderstanding of how this relationship is supposed to work. And it goes both ways: both Fedorans and Red Hatters misunderstand this and mischaracterize it in ways that are counterproductive. So I guess, in the end, what I want to see is RHEL becoming more like Fedora: more participatory and better able to respond to the needs of the community as well as Red Hat's customers. To me, I think ELN, when done right, can do just that. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
