On Thu, May 20, 2021 at 2:30 PM Peter Georg peter.georg@physik.uni-regensburg.de wrote:
On 20/05/2021 20.11, Neal Gompa wrote:
On Thu, May 20, 2021 at 2:08 PM Peter Georg peter.georg@physik.uni-regensburg.de wrote:
On 20/05/2021 17.22, Patrick Riehecky wrote:
Adding notes in line below:
On Wed, 2021-05-19 at 17:56 +0200, Peter Georg wrote:
Dear all,
I'd like to propose a SIG for CentOS Stream. Please see the proposal below.
Note: In case anyone has a better suggestion for a name, please let me know. I'm really terrible at naming things. And sorry in advance for any spelling or grammar mistakes (I'm not a native english speaker).
For everyone following the previously posted "RFC: Stream Kernel SIG Proposal": The goal of the "kmods" SIG proposed here has previously been proposed to be added to a potential "Stream Kernel SIG" as a fifth goal. However it seems to make sense to split the various different goals into seperate SIGs.
Disclaimer: I used the Hyperscale SIG description ( https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.centos.org_Special... ) as a template. I hope that's OK.
The more we can reuse things that work and make a cleaner/better/easier process the happier we will all be :)
Best,
Peter
Proposal: = kmods SIG =
== Goals == The kmods SIG will focus on providing kernel modules currently not available in CentOS Stream.
== Status == Proposed: RFC and looking for a sponsoring Governing Board member
As a board member I hereby indicate a willingness to sponsor. If another board member is passionate about this, I'll be happy to hand it over to them. I've regularly made use of external kmods (for old hardware and proprietary hardware)and would strongly like to see them continue in Stream!
== What's in scope == This SIG is a good place for any kernel module that is beneficial to CentOS Stream, but cannot be directly contributed to any of the involved upstream projects. These kernel modules may be divided in three categories:
=== Restore support for deprecated devices === The CentOS Stream kernel includes several kernel modules for which the list of supported devices has been limited by Red Hat. This SIG aims to many deprecated and removed devices as possible.
A close collaboration with the kernel-plus developers is desired for these kernel modules.
=== In-kernel modules not enabled for CentOS Stream === Many in-kernel modules are simply disabled for the CentOS Stream kernel. This may either be due to drivers being deprecated and removed compared to older CentOS major releases or never being enabled in the first place. This SIG aims to provide these in-kernel drivers as external kernel modules to enable CentOS Stream running on a broader range of available hardware and provide other beneficial functionality.
A close collaboration with the kernel-plus developers is desired for these kernel modules. In addition it is desired to work with upstream to get any valuable kernel modules directly into the CentOS Stream kernel.
=== Third-party external kernel modules === This SIG also aims to provide third-party kernel modules for CentOS Stream not (yet) available in upstream kernel.
== What's not in scope == Anything that can be contributed directly to any of the involved upstream projects is not in scope. This includes, but is not limited to:
- New user space packages: These should be submitted to Fedora/EPEL
- Support for new architectures currently not supported by CentOS
Stream
- Third-party kernel modules with non compatible license
Echoing other thoughts, packages in EPEL should be installable by folks with or without the SIG. So I'd suggest anything that isn't dependent on the kmods, should go into EPEL, but things that are kmod specific should probably stay within the SIG. In theory, if userspace is tied to the kmod, synchronizing updates would be cleaner if things were in just the one place.
Makes sense. I'll wait for further input on this point and will then try to come up with a better solution.
I'm a bit concerned that "non compatible license" is a bit vague. Would this exclude DRBD, ZFS on Linux, OpenAFS, or nVidia? The nVidia bits seem to be 'yes, it is excluded', I'm less sure on the other two.
Concerning your examples: Afaik the CDDL (ZFS) is considered a free software license by the FSF. So I assume this should be fine. The nVidia bits are probably not allowed.
OpenZFS has not been allowed per Red Hat Legal, so I don't think you can do that.
Well, as I said: I'm not a lawyer :) But good to know, thanks!
Does this mean that legally the same restrictions that apply to getting a package into RHEL also apply to packages provided by a CentOS SIG?
Yes.