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

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!