On 18/02/2021 20.40, redbaronbrowser via CentOS-devel wrote:
On Thursday, February 18, 2021 11:13 AM, Peter Georg peter.georg@physik.uni-regensburg.de wrote:
Responding to my own message as there seems to be low interest.
@Brian Stinson: Any suggestions on how we could proceed in this matter?
I'm not sure why there is so little interest in this endeavor. There at least seems to be some demand for kmods to support Hardware not supported by the CentOS Stream kernel (see question about ELRepo on #centos-devel few days ago). Having the recent announcement about EOL of CentOS Linux 8 in mind, I assume a possible explanations (at least for this case) is that (CentOS Linux 7/8) users:
haven't decided yet what to do once CentOS Linux 7/8 is EOL.
are planning to move to a free RHEL subscription or an other RHEL downstream rebuild (AlmaLinux, RockyLinux, etc.).
tried to run CentOS Stream 8 and realized these kmod packages provided by ELRepo and others are not working anymore. These probably stick with CentOS Linux 8 for now and switch a) to an alternative RHEL downstream rebuild (AlmaLinux, RockyLinux, etc.) before EOL (supported by ELRepo and others); b) to CentOS Stream 8 once someone has fixed this issue.
Just my guess. Anyway, to allow users currently running CentOS Linux 8 (i) with kmods provided by ELRepo and others or (ii) running the CentOS Linux Plus kernel to switch to CentOS Stream 8 without changing hardware, one should either provide (i) an alternate source for these kmods or (ii) build CentOS Stream Plus kernel. Has anyone heard from Akemi / toracat about plans concerning building the plus kernel for CentOS Stream?
As I already mentioned in one of my previous emails, I do need some of these kmods locally and hence build them for CentOS Stream anyway. I do not mind the extra work (actually it might be lower once all ist set up) to provide the kmods to other CentOS Stream users as well.
I currently have SPECS ready for:
Rebuilds of upstream drivers supported by RHEL with (almost all) deprecated adapters [1] re-enabled: aacraid, be2iscsi, be2net, lpfc, megaraid, mlx4, mpt3sas, qla2xxx, qla4xxx
Upstream drivers not supported by RHEL: isci, sky2
Wireguard
The second group of packages is actually more complicated to maintain than the first. Wireguard and others highly depend on upstream support.
Is there any reason why one should not be able to build these packages in CBS? Note: The kernel modules are currently not being signed.
Just let me know how I can move this proposal forward. If there is no interest by anyone, I'll just keep on building the packages I do require in private.
I like your drive to help get this done. I also like that Brian Stinson made the effort to be available to listen.
However, if your read forums outside of centos-devel, it seems clear there is a lot of distrust Red Hat and CentOS at this point.
Your list of possible explainations seems to be an acknowledgement that you are aware of that.
The migration of Stream having the resources to be an Upstream should have started back in 2019. It should have been able to use those resources to organically shifted CentOS 8 users into Stream 8 users. Instead of building Stream 8 up into something that provides benefits over CentOS 8, they decided to force the issue. They then announced the free RHEL licenses still without having made any additional resources available to Stream 8 users. This behavior clearly puts Stream 8 at a huge disadvantage for interest and adoption.
It would be nice to be able to help shape that Technology Previews of RHEL 8 such as getting Wireguard added. While it seem implied that in theory the new focus on Stream can make that possible, it seems from a practical sense that is still all just vapor.
Key questions I still can not find the answer to:
What is the expected lifespan remaining on Stream 8?
What is an itemized list of resources Red Hat plans to make available for us to better contribute to Stream 8?
What is the progress status on each of those items for making those resources available?
Can we please not turn this into yet an other discussion about what CentOS Stream is and what it should be? We know what it is now. We have heard about what is envisioned in the future. Community members have raised their concerns and wishes/visions.
I offer my help to improve the current version of CentOS Stream 8. This does not depend on any of the proposed future features to be available.
So far CentOS should still have a head start in attracting SIGs around Stream. But AlmaLinux has stated they are setting aside $1 million per year in funding their project. It seems to me at some point this year they will have their own community manager and resources for SIG groups. There is only so far KW's blog post issing platitudes of theoritical advantages can hold the interest of the community. > Overall, I think you are attributing lack of faith in Red Hat with lack of interest. There should be plenty of interest in the goals you are trying to accomplish but people have gotten sick of ramming their head into a brick wall. Stream 8 is in such a vague state at this moment there is nothing to really build interest around. As long as people are stuck in a wait and see mode, they might as well wait to see what other evolving clones will be offering to SIGs.
Maybe I mistake lack of interest with lack of faith, but this doesn't really matter. The consequences are the same.
For my needs Stream 8 is very similar to Linux 8: The only difference is removing an artificial border that previously allowed (non-security) updates to only happen twice a year. Whether this is a good or bad change depends on your personal needs.
There are other proposed features I'm interested in. However, these are not yet available.
Feel free to try emailing centos-questions@ about when we should be able to contribute into CBS and get signed Wireguard modules. See if you get anything close to a practical answer to that.
I will not email centos-questions@ about this matter as I prefer to discuss in the open and centos-devel@ seems to be the right place.
Best
Peter