On 28.12.2020 00:27, Alexander Bokovoy wrote: > On su, 27 joulu 2020, Konstantin Boyandin via CentOS-devel wrote: >> 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 find it strange to add 'paid' where it is not necessary needed to be > if you have no facts to say so. In fact, Chris Wrights blog is very > explicit: > https://www.redhat.com/en/blog/centos-stream-building-innovative-future-enterprise-linux > > "In the first half of 2021, we plan to introduce low- or no-cost > programs for a variety of use cases, including options for open source > projects and communities and expansion of the Red Hat Enterprise Linux > Developer subscription use cases to better serve the needs of systems > administrators. We’ll share more details as these initiatives coalesce." "low" is in accordance with "paid". As for "as these initiatives coalesce", I see yet another vague promise. Looks like this decision has been taken *post factum* and was, so to say, unplanned. [...] >>> 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. > > The simplest solution for these use cases is to actually report a bug > against RHEL and/or CentOS Stream and make sure it is reproducible. This > would be the quickest way to get the issue backed out or fixed in a > number of days. There are means to remove broken packages from RHEL > composes and I hope we'd have a way to propagate those 'removals' to > CentOS Stream. > > This is something worth raising as a feature request if it doesn't exist > yet. I have doubts it would ever work, but it's worth trying, just to make sure. -- Sincerely, Konstantin Boyandin system administrator (ProWide Labs Ltd. - IPHost Network Monitor)