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

Mon Dec 28 11:43:12 UTC 2020
Phil Perry <pperry at elrepo.org>

On 28/12/2020 08:02, Alexander Bokovoy wrote:
> On su, 27 joulu 2020, Gordon Messmer wrote:
>> On 12/27/20 4:31 PM, Ljubomir Ljubojevic wrote:
>>> On 12/27/20 5:00 PM, Alexander Bokovoy wrote:
>>>> I can see two major ways of enabling 3rd-party drivers:
>>>>  - using elrepo's excellent work on kmods to build a CI for CentOS
>>>>    Stream kernel updates and perhaps block updates based on CI 
>>>> results'
>>>>    consensus (not necessary blocked until it 100% green)
>>> Phil Perry from ElRepo project wrote extensively both on [CentOS] and
>>> [CentOS-devel] lists why that aproach is not viable.
>>
>>
>> I might be misreading one party or another, but I believe that what is 
>> being proposed is better integration of ELRepo's kmod packages and 
>> CentOS Stream, so that kernel updates aren't published until the 
>> modules build.  And if it is, then I'm not sure why that approach 
>> would not be viable.
>>
>> Neal Gompa wrote: "The correct fix here is to start blocking RHEL 
>> kernel updates
>> against third-party Free Software kernel module packages to ensure
>> compatibility isn't broken and the kernel ABI stops breaking on every
>> kernel version series. The reason it keeps breaking is because there's
>> no current mechanism in which these are tested together to validate
>> them for release."
>>
>> That seems like an ideal solution.
> 
> You are getting it right, Gordon, thank you for connecting the threads.
> 


So if I understand correctly, the proposal is that if a 3rd party 
(elrepo or OEM) driver does not build against a Stream kernel, you would 
not release the kernel? That would mean to date there would not be any 
Stream kernel updates released[1] because _something_ breaks against 
*all* of them? Or have I misunderstood what is being proposed? That 
would be a real shame for those folks who would like to test new 
functionality and/or participate and feed back in the development process.

And when the above situation arises (an elrepo or OEM driver fails to 
build and/or weak-link against a Stream kernel), what would be the 
process to fix that? Elrepo drivers are developed against and built for 
RHEL kernels, so when they fail to build for Stream, that won't get 
fixed for upto 6 months until the next RHEL point release. Or to put it 
another way, elrepo is a downstream project, downstream of RHEL.

[1] Caveat that I've only personally tested Stream kernel releases since 
RHEL8.3 was released (kernels -257 and -259) but I would be highly 
surprised if the situation was any different for Stream subsequent to 
earlier point releases.