> I have no illusions that this message is going to change anything at Red > Hat. It's not really for us as community members to identify a business path and that is a convenience factor that we typically rely upon to work on things that begin as experimental and a learning path only to grow into something more reliable and service-ready. > First a bit of background. I came to Red Hat via the Cygnus > acquisition. My combined service spanned nearly 30 years. During that > time I had the opportunity to be involved in the formation of Fedora, > strategic planning for RHEL while at the same time being able to spend > much of my time on optimizing compilers. > Thank you for your contributions over the years and for continuing to do work at such a low level. It helps the rest of us stay focused on delivering a great experience to users knowing that the subsystems we rely upon are not going to fail us and that they deliver the best performance possible. > -- > What Red Hat has done recently is depressing, but not a huge surprise to > me. Red Hat struggled repeatedly with how to deal with "the clones". [. . .] > Arguments for protecting the bits were > met with something like "if that's what we need to do to be successful, > then we're failing to provide real value". > I disagree that this is "protecting the bits. The bits are equally available to all and that's how we do what we do in this Fedora community. I see it as more of a hard nudge from the comfortable nest of a basic rebuild to determine a pathway forward as a clone. This is not a bad time to do it. As we move towards more immutable systems and the use of container-based workloads in production - it's time to ask after whether or not we should deemphasize these paths forward. This probably sounds bizarre coming from someone who works hard to preserve the cloud edition experience side by side with the immutable FCOS and IOT editions, but I recognize that there are places for both and that the sun will eventually set. Furthermore, the CentOS Stream process is stabilizing and consistent with the goals of the community. I was at devconf.cz recently and I sat down with Tomas and Nikolas from the Packit team to really dig in to how I can make packit and copr work for more rapid development and how I can ensure that my builds are consistent with the goals of both the upstream and downstream communities. In my experience with the CentOS community, I have spent countless hours helping users taint the very kernel they declare they want to preserve to get the results that are already built into the CentOS Stream experience. I think, just like Mike McGrath and probably a lot of people, that this is the best code base to expose and that we should be, as a community, determining how to roll forward. Sure there will be requirements for freezing support, but there are mechanisms for this already - os-build will give you a resource for experimentation. There are package manifests to ensure consistency between states, but just generally, users push forward with the systems they don't purchase support to run. I am not saying there aren't reasons to freeze updates, etc. There are, but as CentOS Stream _is_ RHEL in it's next form it is also representative of where RH would like the community to be. If we as a community care about our evolution, then the clones should care about it as well. If Red Hat as a sponsor identifies that the bar is better set at CentOS Stream it is more a statement on where they believe that CI/CD and Quality Engineering has set the bar for user stability. > Back in 2002 or 2003 when we were trying to figure out how to salvage > the ill-fated "Red Hat Community Linux Project" resulting in what we now > know as Fedora, one of the key concepts that we pushed to the > executive team at Red Hat was that it was strategically important for > both Fedora Exactly! And projects like Fedora ELN that Stephen Gallagher, et. al., have dedicated themselves to supporting are only bringing it closer. > I've been a Fedora user since before FC1. I run Fedora on my laptop. I was not as much a part of the division as you were, but I was there as a community member and contributor. I was out in the field though, putting it on systems that replaced routing for T1 lines with Fractional T1s and DSL that eventually turned my business users into Red Hat customers. I get the appeal of a strong union between the two. > That will change across the board this summer. [. . .] I don't see the change, on the contrary, I see a more unified community rallying around the special interests of the clones similar to the way the Hyperscale SIG unifies the more advanced requirements of fail-only architectures in CentOS Stream right now. Those same contributors to the Hyperscale SIG are also supporting work on Fedora Asahi and Fedora ELN just as fast! ( I am looking at you Davide and Neal). I am betting on the community to welcome the clones and help them find their dividing lines as well as accept their fixes and assist them in their CI and validations. This Red Hat decision didn't exclude the clones, it just made the fact that the bar has been set higher for community participation a more clearly defined action IMO. > > I'll still have to deal with the RHEL/CentOS/Fedora ecosystem on a > professional level. Obviously, I'll do what I need to do to help make > my employer successful -- but when a choice exists, Fedora/CentOS/RHEL > won't be where I land going forward. So I am terribly surprised by the statement that you won't be coming with us. I see you as someone who could really help the clones be a part of the community and help them navigate the early introduction into the CentOS Stream and ELN communities. If you ever decide to return as a Fedora/CentOS/RHEL user for your own reward, I'll be in the line that welcomes you back and looks forward to your help. -- David Duncan _______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
