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. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland