On su, 27 joulu 2020, Konstantin Boyandin via CentOS-devel wrote: >On 27.12.2020 21:48, Alexander Bokovoy wrote: >> On su, 27 joulu 2020, Ljubomir Ljubojevic wrote: >>> On 12/27/20 12:29 PM, Alexander Bokovoy wrote: >>>> On pe, 25 joulu 2020, Ljubomir Ljubojevic wrote: >> >> Following your approach to a detailed information about the Stream, >> we've been told there are various RHEL subscription programs coming next >> year that would address use of RHEL for many existing CentOS users. > >-various RHEL subscription programs >+various *paid* RHEL subscription programs Let's be clear: the above 'diff' is your own opinion and a speculation, not based on any public information. There are no facts that would support a claim that future RHEL subscription programs we are promised will all be paid ones. I certainly hope some of those programs would support free use of RHEL. https://www.redhat.com/en/blog/faq-centos-stream-updates#Q12 unfortunately does not give a clear 'fee' or 'free' clarification yet but it certainly does not claim they will all be paid ones. >> Perhaps, those programs would address the needs of consumers of >> 3rd-party drivers too, before we'd reach the collaboration ideal I >> outlined above. Let's see how that goes. > >Looking-glass (upside-down) marketing? > >Normal approach would be "study the community needs -> develop and >announce subscription plans -> announce CentOS shutdown". > >Something tells me the above steps are being applied in reverse order >(with 'study" step optional). I have had no exposure to how the process was done. I am looking here at a way to produce something that would work in future, not spending time to fight with a past. Can we focus on the future? This is development list, after all. I can see two major ways of enabling 3rd-party drivers: - using elrepo's excellent work on kmods to build a CI for CentOS Stream kernel updates and perhaps block updates based on CI results' consensus (not necessary blocked until it 100% green) - for proprietary drivers make sure there are clear ways to enable those partners to plug into the same process as an external CI. Both can be achieved by forming a SIG, contributing some resources, and having a shared set of common CI tools. CKI already gives a platform to base on, for kernel-specific components. Fedora Project already gives a way to organize CIs around similar topics for other components, so reusing the tooling is definitely possible. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland