[CentOS-devel] Balancing the needs around the RHEL platform

On Thursday, December 24, 2020 7:05 PM, Mike McGrath <mmcgrath at redhat.com> wrote:

> On Thu, Dec 24, 2020 at 3:59 PM redbaronbrowser via CentOS-devel <centos-devel at centos.org> wrote:
>
>>> On 12/24/20 12:01 PM, redbaronbrowser via CentOS-devel wrote:
>>>
>>> > In terms of balancing the needs of the CentOS platform and the
>>> > openness gap, the CentOS governance board should be focus on if the
>>> > CentOS Stream kernel SRPM should be of the same quality as Fedora's
>>> > kernel SRPM. Or if pre-applying patches in a non-open way is acceptable.
>>>
>>> At that point, is the question you're asking whether or not the CentOS
>>> kernel should be a rebuild of an RHEL kernel SRPM? These don't seem
>>> like questions that the CentOS maintainers would have ever even accepted
>>> for consideration.
>>
>> In normal times, I wouldn't think of suggesting this.
>>
>> The year of 2020 is clearly not normal times.
>>
>> CentOS Stream is a new age. We are the upstream now. We should be able to choose the kernel and the quality level of the SRPM.
>>
>> I believe what makes something CentOS is the governance.
>>
>> Red Hat's behavior makes it clear they believe what make something CentOS is who owns the trademark. That they can lie about the governance rules to get whatever they want.
>>
>> This militant attitude on the part of Red Hat and the fraudulent governance board deserves an equally militant response.
>>
>> Time fix the openness gap for the kernel SRPM for real instead of blindly following Karsten Wade's empty posturing in the name of openness.
>>
>> Let's also fix the availability gap. Karsten Wade vision for CentOS Stream is that 95% is good enough. For every 1 million users there are 50,000 that have their needs fall through the cracks. I think as a community we can provide better results than that.
>>
>> Both openness gap and availability gap are worthy things to fix so let's fix them. But Karsten Wade isn't offering an effective fix for those issues.
>
> I agree with you the governance model needs work. You've called out Karsten a couple of times but it's not clear to me what his role is going to be for CentOS Stream going forward. That is to say, there are others also involved in CentOS so you may not want to single him out.

It does not just need work. If I submit an RPM for inclusion in Fedora that violate policy, I don't get to say publish it anyways and we will work on the policy issue later. Nothing can proceed until the policies are honored.

In the case of terminating CentOS 8, governance policy requires the following be done to proceed:

(1) A transcript of the previous Governance Board meeting to be publish

(2) Brian "Bex" Exelbierd must resign from the Governing Board

(3) The issue of gutting CentOS 8 should be re-presented before a valid Governance Board meeting which is public, open and inclusive.

> There are a few boundaries I know Red Hat would like to keep in place.

You can claim all the boundaries you want. If Red Hat is willing to lie and abuse it's ownership of the CentOS trademark to do whatever it wants then claims of boundaries stop having meaning. Instead we are being given transient guidelines in which Red Hat will self-impose or dismiss at anytime.

> 1) The mainline branch *is* RHEL and so anything that gets committed there must be merged by a Red Hatter.

Yes, I already figured out for myself that Red Hat is recreating Windows Insider builds. We will continue to have Fedora as the fast ring. But RHEL now wants a slow ring as well. I agree there are advantages to having a RHEL Insider Slow Ring. However, I don't agree that it should involve CentOS at all. This definately can't justify putting Bex on the governance board in violation of stated CentOS policy.

> 2) No attempting to do another downstream rebuild (for those that desperately want to contribute to this, there are already other communities for it and we won't be competing with them)

Then it stops being CentOS. If the people that used to work on CentOS now need to work on something else, then we probably can't stop Red Hat. But even if it involves some of the same people doesn't make it the same thing.

Some of the people that contributed to Python have also contributed to Nodejs. If I submit to Fedora an RPM called Python4 that uses the Nodejs source code, the RPM would be rejected as misleading. What Red Hat is doing is the same of releasing something under a misleading name. What makes CentOS is "[CentOS] retains an upstream."

There are plenty of other names Red Hat can use for Red Hat Insider Slow Ring. You can try recycling any of these names Picasso, Rembrandt, Colgate, Vanderblit, Biltmore or Baron. Or whatever you want.

If a valid CentOS governance board decides CentOS needs to die, then it needs to die. But please don't hand the name of the dead to an identity theft.

> 3) We want a robust SIG community, and that includes welcoming things that Red Hat isn't particularly interested in. So when we say no to something in the mainline branch, SIGs should be a fairly safe place to do that where they can use official build infrastructure and distribution mirrors. I've heard many people talk about special kernel needs, enabling older hardware, kabi, etc. I'd love to see that done in a SIG. I also personally think the bar for starting a SIG should be low.
>
> I'm not in the governance game here but the question for you, and others, is this - What sort of governance model can we put in place to accomplish these goals as well as whatever common goals we have going forward? What are our common goals from here? I've seen many technical issues brought up on the list over the last two weeks that seem solvable to me

We already have SIGs for RHEL Insider Fast Ring (Fedora) and a governance board for them (FESCo). They should be able to determine what SIGs should also provide builds for RHEL Insider Slow Ring.

When you say there are technical issues that are solvable, can you list what those are?

Are we ever going to close the openness gap for the kernel SRPM? Or are we expected to assist with troubleshooting RHEL Insider Slow Ring with our hands still tied behind our back because there is no explicit information what makes up each patch?

You have taken notice that I have brought up Karsten Wade multiple times. But you seem to have gloss over the reason why. I still have not gotten an answer as to if Wade's claim that Red Hat's desire to close the openness gap is genuine. Or is it a self-serving definition of openness gap that excluses fixing the kernel SRPM.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20201225/6863474c/attachment.html>