[CentOS-devel] Balancing the needs around the RHEL platform

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."


>> 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.

Yep.

>
>>>> 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.

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.


-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland