Second, where there's overlap, let's look at merging Fedora and CentOS SIGs into joint bodies. We have groups like the cloud image SIGs which are basically doing the exact same thing in two different ways. Same thing with containers. We also have huge overlaps in documentation and community user support and all sorts of non-technical project areas. I'm not saying these all need to be smooshed together, but where it makes sense let's work together. This, too, brings simplification to the "what's with CentOS vs. Fedora" story: rather than making contributors pick, we can welcome all with open arms.
I *love* this idea. We could rebrand them as "Red Hat Community SIGs" that operate in both the Fedora and CentOS communities. I think CentOS SIGs could learn a lot from how Fedora SIGs operate.
While I agree with consolidation, over time, of the SIGs, I do think the name should be “Enterprise Linux Community SIGs” or similar. I get that Red Hat has a massive influence in all four flavours (Fedora, RHEL, CentOS, Streams), but for someone new to the communities, it could be confusing to refer to them as “Red Hat”, as most people outside the community see “Red Hat” as referring only to “RHEL” and not the wider Enterprise Linux ecosystem.
Greg
Gregory Young
From: CentOS-devel centos-devel-bounces@centos.org On Behalf Of Carl George Sent: Wednesday, January 8, 2020 9:30 AM To: The CentOS developers mailing list. centos-devel@centos.org Subject: Re: [CentOS-devel] A Big Idea for a New Decade [was: Minutes for CentOS Board of Directors 2019-12-18 Meeting]
@Matthew
First, let's replace Fedora Server as a user-focused artifact with CentOS Stream. There's still a need for a Fedora Server as an upstream, but most users of Fedora as a server are making custom builds (or using the basic Cloud image), not using Fedora Server per se. So, I think we should stop marketing that to users, and steer people with server use cases outside of the fast-moving niche to CentOS Stream. The current story of CentOS and Fedora is pretty confusing to users, and Stream only makes it more so. Let's simplify things!
I rather enjoy using Fedora on servers. I'm concerned that steering users away from this use case sends a bad message. It's a common misconception that it's a bad idea to use Fedora on servers. I'd rather the project itself not implicitly agree with this.
My personal preference would be for Fedora Server and CentOS Stream to be presented as equally attractive options and let users choose the one that suits their needs. Perhaps the marketing for both could cross reference each other. Fedora Server's marketing could say something like "If you're concerned about the fast release cycle of Fedora, CentOS Stream may be more to your liking". CentOS Stream's marketing could say something like "If you need newer versions of core packages, you may consider Fedora Server".
Second, where there's overlap, let's look at merging Fedora and CentOS SIGs into joint bodies. We have groups like the cloud image SIGs which are basically doing the exact same thing in two different ways. Same thing with containers. We also have huge overlaps in documentation and community user support and all sorts of non-technical project areas. I'm not saying these all need to be smooshed together, but where it makes sense let's work together. This, too, brings simplification to the "what's with CentOS vs. Fedora" story: rather than making contributors pick, we can welcome all with open arms.
I *love* this idea. We could rebrand them as "Red Hat Community SIGs" that operate in both the Fedora and CentOS communities. I think CentOS SIGs could learn a lot from how Fedora SIGs operate.
@Neal
In concept, I certainly see value in bringing CentOS and Fedora closer. However, I think eliminating Fedora variants in favor of CentOS Stream ones (aka rhel-rawhide based variants) is probably premature.
You raised some great points. I want to reiterate this part of Matthew's original email:
"...in this next decade..."
I think it's reasonable to believe we can address the concerns you raised within the next 10 years. Your feedback (and everyone else's) is critical to getting us there, so thank you for sharing it.
@Jim and Neal
So, what this long email is actually saying is that I think it's an interesting idea to bring the two projects together, but eliminating aspects of Fedora in favor of CentOS is premature because CentOS has not actually developed as a community project. Maybe it's worth revisiting after six years of actual community development?
I disagree a bit here. I think it's worth discussing, and I think it's worth being clear about what the expectations are both for Stream, and Fedora Server.
I think we should have the conversation (possibly again) about what we want from Fedora Server. Is it serving the purpose originally envisioned. Should that continue to be the purpose for it, etc.
I think you're both right. I don't want Fedora Server to be eliminated, but I do believe we should have a clear understanding of how they overlap and how they differ in order to present them appropriately to the community.
On Tue, Jan 7, 2020 at 2:09 PM Jim Perrin <jperrin@centos.orgmailto:jperrin@centos.org> wrote: A couple points in-line for clarity:
On 1/7/20 4:09 AM, Neal Gompa wrote:
First, sorry that this email probably doesn't thread will with either one or the other target mailing lists... I had to pick one to thread with, and other slightly loses. The downside of the initial email not being sent to both MLs at once. :(
In concept, I certainly see value in bringing CentOS and Fedora closer. However, I think eliminating Fedora variants in favor of CentOS Stream ones (aka rhel-rawhide based variants) is probably premature. There are several issues with doing this as it currently stands:
- CentOS Koji is pretty closed to a couple of folks in CentOS and Red
Hat. This also includes blocking the download of artifacts from Koji. For reasons I don't understand, CentOS is still gated by the RHEL QE folks, and thus RPMs built in Koji cannot be downloaded until they are finally published. This ruins any testing/development before releasing to users. The CBS is a worthless substitute since it's purely for addons. I've been around long enough to remember when Fedora was like this, and back then, it wasn't really considered "okay" for Fedora to be like that (the intent was always there to fix it, and we eventually did!). Today, however, it is considered "okay", and that's a problem.
There were a variety of reasons this was done initially. In part for bandwidth protection, ensuring debranding, and that packages had some sanity checking (they link appropriately and didn't need to be rebuilt, which happens frequently). Fabian and Brian have kicked around ideas for how we can solve the majority of these issues, so we will be resolving this in the future. We know it's not "okay", but it's also not the biggest problem we need to solve.
- The CentOS community is simply not mature enough to take on the
role Fedora does in any meaningful capacity. We already know that this is a problem even with Fedora EPEL, and I strongly believe the issue would be massively magnified if those transitioned to the CentOS Project. The CentOS community is largely a user community that takes and does not give back much, if at all. I've experienced variations of this issue when people (even from Red Hat!) have done finger-pointing to *me* with my packages in EPEL without any acknowledgement that they could have helped. It's depressing that even some Red Hatters consider EPEL not worth contributing to, but still worth being upset about.
That's because until Stream existed, there wasn't really much of a way to give back that didn't make the project deviate from its core mission. We have absolutely taken contributions from the community in the past, but most of the fixes offered were to fix bugs we didn't "own".
Stream gives us the opportunity to solicit and accept contributions, so this point feels like it's holding the past up as a reason to not address the future.
What I'm more concerned about is that if you eliminate Fedora from any meaningful server based development, you strip all the opportunities for people to iterate on server-oriented changes before they go into rhel-rawhide and push into CentOS Stream. You also essentially kneecap any motivation for other things related to server environments to iterate faster (such as language stacks that are heavily used for web service software) because you've eliminated the major ability for that to ship to users and contributors. It also further accelerates a trend that I think we need to reverse where people consider Fedora unacceptable for server roles. If anything, Fedora is a lot better at being used for servers then it was five years ago. I've personally *stopped* using CentOS for servers because Fedora has gotten so good at it. Upgrades are a breeze and stuff generally works. When it doesn't, it's fixable! That last part is key. With CentOS, it's not, because it has to bounce back into Red Hat first. And Red Hat doesn't really care about issues discovered by CentOS users, and there are no "CentOS developers".
I'd like to see more data driven discussion and to take the feelings and ego out of it. Anecdotal stories lead toward the loudest voice winning instead of the largest mass of users. This does assume that we (both Fedora and CentOS) have discussed which goals and metrics matter and should be used to shape a decision one way or the other.
So, what this long email is actually saying is that I think it's an interesting idea to bring the two projects together, but eliminating aspects of Fedora in favor of CentOS is premature because CentOS has not actually developed as a community project. Maybe it's worth revisiting after six years of actual community development?
I disagree a bit here. I think it's worth discussing, and I think it's worth being clear about what the expectations are both for Stream, and Fedora Server.
I think we should have the conversation (possibly again) about what we want from Fedora Server. Is it serving the purpose originally envisioned. Should that continue to be the purpose for it, etc.
Stream is what RH *intends* to be in future versions of RHEL, and I think that intent matters when it comes to people developing for oVirt, RDO, ansible or something else that would run on top of RHEL. I think that intent matters for feature development when CERN or FERMI have fixes or input for things they want to see, and contribute code to make it happen. It will still be RH that makes the decision to commit to accepting those fixes and agreeing to put them into future RHEL releases. This is what we're actively building out, and what Carl is working on.
-- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.orgmailto:CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Carl George