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.