> 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.
There are a few boundaries I know Red Hat would like to keep in place.
1) The mainline branch *is* RHEL and so anything that gets committed there must be merged by a Red Hatter.
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)
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.
-Mike