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

Sun Dec 27 16:00:23 UTC 2020
Alexander Bokovoy <abokovoy at redhat.com>

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.

I certainly hope some of those programs would support free use of RHEL.
unfortunately does not give a clear 'fee' or 'free' clarification yet
but it certainly does not claim they will all be paid ones.

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

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.

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