On 19/05/2021 18.05, Neal Gompa wrote: > 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. I cannot contradict your argument. The example I thought about when I wrote this is wireguard: The kernel module is not available in RHEL 7 and 8, but wireguard-tools is in EPEL-7 and -8. Not sure about the EPEL policies in this case. At the end we'll probably have to deal with it on a case-by-case basis. Let me think about a better wording, or whether it is better to simply drop that one point. >> == 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? There is obviously a large overlap with ELRepo. Phil Perry has been involved in previous discussions about this matter. And I think that he and others know that I'm in no way trying to compete with ELRepo, but instead trying to bring some of the great features ELRepo provides for RHEL (and its clones) to CentOS Stream. So despite not really answering your question, I just wanted to note that I'll be happy to work with ELRepo (and the kernel-plus maintainers). I also wanted to note that the question about CBS having RHEL buildroots might also be interesting for other SIGs: Before CentOS Stream every SIG has been building for CentOS Linux, allowing the SIG repos to be consumed by RHEL users as well. Now with all SIGs moving from CentOS Linux to CentOS Stream this is not the case anymore. Are there any SIGs that plan to target both CentOS Stream and RHEL (or one of its clones)?