On Thu, May 20, 2021 at 2:30 PM Peter Georg <peter.georg at 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 at 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_SpecialInterestGroup_Hyperscale&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=pGCREeRni9c5EX2L12UG18KzS_jp_PQxqbJohJOAHmI&s=Y8Rc2wfIQTiG6pW9V55QTQmMkjJEFYkhtAZdWRjBXlA&e= > >>>> ) 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. -- 真実はいつも一つ！/ Always, there's only one truth!