Hi, Neal, On Wed, May 13, 2020 at 9:24 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > 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! Huge +1 here! > 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). While I can recognize some of those notes, I think you are unnecessarily amplifying them. Note that Red Hat is not a hive mind. It is a big company, which is also full of grumpy engineers and similarly grumpy managers. And if you catch me in a wrong mood, I can go rant on how I wish I could just tell people to do the right thing, and not spend hours on explaining why exactly it is right to them. I don't have such power, and I will never _really_ wish for that kind of power, but, you know, everyone has its moments. It doesn't make me disrespectful to the Open Source community. And it literally has nothing to do with Red Hat and Fedora. Full disclosure: there is no such power for me or anyone else inside Red Hat either, and I am kind of proud of it. > 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. Nitpicking here, as less than two years old RedHatter and more than 10 years old Fedora contributor, I am actively against separating Red Hatters who contribute to Fedora from the rest of Fedora community. And some of the Red Hatters I know are the most fierce Fedora advocates you can ask for. (I am not that fierce yet, but sometimes I am trying) > 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. Indeed, as Fedora Ambassador I see this happening a lot in various communities, usually already hostile by some other reasons. Over the years I learned to accept the fact that Fedora is indeed balancing on this edge, all the time. It is hard and it is complicated, but we are doing it for quite some time already. With some downsides and upsides, we keep moving. This balancing act on one hand causes frustration, but on the other - it is something which feeds our evolution as a project. If you don't have the downstream, you don't have a use case, which could bring you down to earth and to real world tasks, and you don't have resources to make something big. If you don't have upstream and community, no one challenges your decisions, and no one forces you or teaches you to prove yourself, again and again. But I am quite disappointed that we are discussing this under the ELN topic. As it was designed exactly to not allow this attitude to grow. It is maybe us not explaining it better, or maybe some generic historical baggage, which we carry, played the role. But honestly, it is just sad. For me one of the main achievements (I should probably say challenges, as we haven't achieved it yet), or better, one of the _defining_ properties of the ELN effort is that we keep Fedora Project and Fedora maintainers in charge of the whole thing. This is what we were fighting for, internally and externally. So rather than just creating some place where RHEL engineers can share their code to public (which would be so much easier to do), we create an incentive for RHEL engineers to come to Fedora Project and Fedora community, bringing their work, their expertise and their resources, and putting it into Fedora development under Fedora guidelines. And while it may bring additional conversation topics to non-RedHat Fedora community members, it is actually a much larger challenge for RHEL developers. And people who commit to it, who try to bring something useful to Fedora, who find time to make it work in between of all of their downstream activities, they deserve the respect for what they are doing. They _are_ the Open Source developers, and they are Fedora community too. > 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. I agree with this goal. And, yes, I would love to be called out on specific things, which we are not doing right, and hear suggestions on how we can make it better. -- Aleksandra Fedorova bookwar _______________________________________________ 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
