On Wednesday, December 23, 2020 6:31 PM, Matthew Miller <mattdm at mattdm.org> wrote: > On Wed, Dec 23, 2020 at 09:38:19PM +0000, Phil Perry wrote: > > > > It seems like Wireguard might be a good example of something for an > > > alternate kernel maintained by a SIG. (Like the Xen SIG does.) > > > Why would you do that? The method we use in Enterprise Linux to > > > deliver 3rd party out-of-tree drivers is the RHEL Driver Update > > Because it's an out-of-tree but open source driver. > > > If Red Hat really wanted to fix this in (a) kernel, the solution > > would have been to accept the repeated upstream requests to backport > > the driver into the RHEL kernel, but that idea/request has been > > rejected. > > Right, Red Hat's gonna make business decisions about what goes into the RHEL > kernel, and pulling in out-of-tree backports is pretty expensive. But this > is exactly the kind of thing CentOS SIGs are empowered to do. See again the > Virt/Xen SIG. Tools like CentOS SIG or DKMS can be useful in some cases to get the module built. There is still a bigger picture. What about when there is a bad interaction between WireGuard and a patch in the latest kernel for CentOS Stream? How do you roll back patches in a SRPM that has no explicit details on which patch the code modifications came from? Please compare the content of a Fedora kernel SRPM with a CentOS Stream kernel SRPM. Then explain how it is justified for Karsten Wade to say this change is because Red Hat cares about the openness gap now. Not only did Red Hat violate that RHEL team would not cross the firewall to interact with the CentOS by putting Brian "Bex" Exelbierd on the goverance board itself, we are also fed another lie that Red Hat cares about the openness gap. The content of the CentOS Stream kernel SRPMs is clear written proof that the openness gap is willfully by Red Hat's own design. False pretenses was given during the joining in 2014 and again now. How is that not supposed to be upsetting?