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

Sun Dec 27 16:50:02 UTC 2020
Konstantin Boyandin <lists at boyandin.info>

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.


Konstantin Boyandin
system administrator (ProWide Labs Ltd. - IPHost Network Monitor)