On 5/19/21 10:09 AM, Peter Georg wrote: > On 18/05/2021 19.44, Rich Bowen wrote: >> >> >> On 5/18/21 6:43 AM, Peter Georg wrote: >>> >>> So in case there is any way to move this SIG proposal forward, or >>> some other more suitable way (under the umbrella of centos-plus or >>> some other SIG?) to provide such kmod packages, please let me know. >> >> I'm not certain if this is what you are asking, but the way forward >> with the SIG proposal is to write a SIG proposal, and bring it to the >> Board of Directors. > > Indeed it was not what I was initially asking for. However this answer > of yours, and the one to redbaronbrowser later, caused me to take a step > back re-think about how to approach this: > > The possible SIG named "Stream Kernel SIG" discussed in this topic here > has been initially brought up by redbaronbrowser and included 4 goals. I > later proposed to add building kmods as a fifth goal. redbaronbrowser > described his idea of a possible SIG in the inital post. However I'm not > sure this qualifies as a proposal. In addition, as you mentioned, there > are some open questions. I think these questions are mostly related to > the initial goals #1, #3, and #4. IMHO some of these goals are not > feasible within the scope of a SIG. > > Hence I'm now thinking about splitting the fifth goal from this "Stream > Kernel SIG" and write a proposal for a "kmods" SIG only containing this > particular goal. > > Whether one wants to add the second goal of redbaronbrowser's initial > idea - building the CentOS Plus kernel - is a different question and imo > up to the current devolpers/maintainers of kernel-plus. This can be > discussed later. > > Before I start writing a proposal for a "kmods SIG": Does this make > sense to you? Yes, it makes sense to me. The board seems more disposed to consider SIGs that have a clearly defined scope. The broader the scope is, the more difficult it is to write an understandable proposal, and for people to understand what's in scope and what's not. And, presumably, if there's a lot of overlap, SIGs can be merged or split in the future to clarify. These things aren't immutable.