> 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. Fedora is not Enterprise Linux. To me, the name "Enterprise Linux Community" excludes Fedora. I'm not married to the name "Red Hat Community", but it's the best name I can think of that accurately conveys the scope. What term would you use to describe the entire ecosystem of Fedora, RHEL, CentOS, CentOS Stream, and EPEL? I've always called this the "Red Hat ecosystem". On Wed, Jan 8, 2020 at 9:20 AM Young, Gregory <gregory.young at solarwinds.com> wrote: > >> 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 at centos.org> *On Behalf Of *Carl > George > *Sent:* Wednesday, January 8, 2020 9:30 AM > *To:* The CentOS developers mailing list. <centos-devel at 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 at 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: > > > > 1. 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. > > > > > > 2. 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 at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > > > > > -- > > Carl George > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > -- Carl George -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200108/653ba343/attachment-0007.html>