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.