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