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. -- Sincerely, Konstantin Boyandin system administrator (ProWide Labs Ltd. - IPHost Network Monitor)