On 27.12.2020 23:00, Alexander Bokovoy wrote:
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.
Let's be clear: quantifier "all" is your own interpretation and was not assumed in my statement.
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.
We will see, although it would be much more logical to know the options *before* the CentOS Linux EOL announcement.
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.
Certainly we can focus on the future. I just comment what I see and can only hope that upside-down approach won't become a habit.
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.
The primary moot point of CentOS Stream usability, as I see it, is lack of simple means to rollback (one or more) packages, to restore a predictable software behavior after another daily update breaks something.