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

Mon Dec 28 10:34:17 UTC 2020
Alexander Bokovoy <abokovoy at redhat.com>

On ma, 28 joulu 2020, Konstantin Boyandin via CentOS-devel wrote:
>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.

You keep ignoring 'no-cost' part there. 

As for how decisions were taken, there was plenty of details published
from the people involved (I wasn't).

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

Not that there are no examples of failing programs anywhere, but keeping
yourself to a darker tone all the time isn't a great way to improve.
Please file bugs/process requests and we'll see how those can be handled
as a part of CentOS Stream programs.


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