On Fri, Dec 11, 2020 at 8:41 AM Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 12/11/20 2:02 PM, Josh Boyer wrote:
On Fri, Dec 11, 2020 at 6:43 AM Louis Lagendijk louis@fazant.net wrote:
On Thu, 2020-12-10 at 20:02 -0500, Konstantin Boyandin via CentOS-devel wrote:
What's not nice is that CentOS community will inevitably be disrupted and dispersed.
Unless the RH announcement was a shortsighted and dumb sacrifice to Money, I assume they just brush away what they consider "unnecessary expenses". In any case, I continue to evangelize open source, Linux included, it's just CentOS and RH that won't be promoted (by me) any more.
I interpret the Centos change of direction as indicative of the change in direction for RedHat: RHEL has become much less important as IBM focuses on web applications, cloud tooling etc. That is where the money is and that is what they bought RedHat for. So RHEL has to optimize OS costs as is it no longer key. So it is only logical to optimize the development process and outsource some of the testing to the public in Centos Stream, and not waste resources on a true free competitor for RHEL.
Now For Stream I am mainly worried about 2 things: 1 - the kernel and its impact on drivers from Elrepo and other external repos (OpenZFS!). Not important for RHEL, but important for people that use old hardware that requires drivers not in RHEL.
Others have expressed this concern, and it's a good one. It would be interesting to see if someone could create a CentOS Stream SIG that did automated rebuilds of those drivers with every Stream kernel update.
The whole idea ( ok, maybe not the whole but certainly one of the most important ideas ) behind ELRepo packages is to take advantage ( as much as possible ) of the weak-modules mechanism and _not_ rebuild the drivers at each kernel update :)
My proposal upthread was to move ELRepo stuff into the CentOS Project as a SIG, and have the CKI SIG that will form to manage the RHEL kernel gate on those kernel modules. The idea would be that breakages would prevent releasing new kernel builds without some kind of acceptance/documentation that there was no way to avoid it, and then those modules would get rebuilt accordingly. This would help make the ABI validation much more comprehensive and help to eliminate the rebuild burden for other kmod developers.
That brings transparency to the process and provides a way for Red Hat and the community to improve the quality of the RHEL kernel's guarantee of a stable kernel ABI.