On ma, 28 joulu 2020, Phil Perry wrote:
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.
Neal and I suggested to be able to use the content (source) of elrepo drivers to be a CI test for CentOS Stream kernel updates. That might be non-blocking, might be blocking if X% of packages fail, might be blocking in 'rings of importance' and so on, it is not needed to be black and white.
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.
If Elrepo drivers have actual developers, getting 6 months advance notification of their driver's failures against upcoming RHEL could be valuable to plan and fix the issues in due time.