On Mon, Dec 28, 2020 at 7:25 AM Alexander Bokovoy <abokovoy at redhat.com> wrote: > > 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. > Yep. There's a lot of opportunity here for what we can do here. The important part is that we have the *data* to figure out *what* to do. > >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. > In general, it would make *my* life easier if elrepo drivers were tracking the RHEL kernel development and getting fixed along the way, because it's a pain when I have to deal with customers who use our stuff and can't upgrade because of broken drivers. That is the situation *now* with CentOS Linux. -- 真実はいつも一つ！/ Always, there's only one truth!