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

On Mon, Dec 28, 2020 at 6:43 AM Phil Perry <pperry at elrepo.org> 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.
>

In my proposal, they would be blocked from being released to users in
the release process unless there's an acknowledgement to release it
anyway by all parties involved (kernel devs, kmod maintainer blocking
kernel release, etc.). They would still exist and be accessible in
something like an updates-testing repo, but they wouldn't be merged
into stable release until a solution is agreed upon.

> 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 the assumption is that the kernel module package shouldn't break,
then the kernel would be fixed. If not, then the kernel module driver
gets rebuilt and released as a new build for that situation. That
provides a consistent upgrade path and keeps people from having to
hold back kernels.

The idea isn't to keep people from getting new stuff, but to ensure
that everyone is able to keep up reasonably well.




-- 
真実はいつも一つ！/ Always, there's only one truth!