On Wed, May 19, 2021 at 11:56 AM Peter Georg <peter.georg at physik.uni-regensburg.de> 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://wiki.centos.org/SpecialInterestGroup/Hyperscale) as a template. > I hope that's OK. > That's totally fine! > > > 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 > > == 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 > provide versions of these kernel modules with restored support for as > 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 > I don't think that it makes sense to ship the user-space packages in EPEL if the kernel functionality isn't present in RHEL. This was something that we went over in Hyperscale with btrfs-progs, and my argument has basically been "people expect EPEL stuff to just work out of the box on RHEL, and we can't offer that with btrfs-progs in EPEL", so now Hyperscale maintains btrfs-progs in CBS. I suspect the same tack will make sense for this too. > == Roadmap == > * Provide packages for in-kernel modules with restored support for > deprecated devices > * Provide packages for in-kernel modules that have been supported in > older CentOS major releases > * Provide packages for further beneficial kernel modules requested by > the community > > == Resources == > TBD > > == Communication == > The SIG uses the > [[https://lists.centos.org/mailman/listinfo/centos-devel|centos-devel]] > mailing list for coordination and communication. > > TBD: Add note about regular meetings once established. > > == Membership == > The current set of members is: > > ##begin-members > * ... > ##end-members > > The SIG is co-chaired by ... and .... > > Everybody is welcome to join and contribute to the SIG. Membership can > be requested by asking on the > [[https://lists.centos.org/mailman/listinfo/centos-devel|centos-devel]] > mailing list. Any current member can raise objections and request a > simple majority vote on membership applications. SIG members are > expected to actively contribute or otherwise remain engaged with the > project. Stale members may be removed by a simple majority vote after > six months of inactivity. > > The SIG is co-chaired by two equal chairpersons elected by SIG members > for one year. Each chairperson is elected individually using a plurality > vote. It might make sense to see if we can bring ELRepo into the fold. A requirement for that would be the ability to build with RHEL in the buildroot, though. Perhaps we can get an arrangement for CBS to have RHEL buildroots like EPEL has? -- 真実はいつも一つ！/ Always, there's only one truth!