On 28.12.2020 17:34, Alexander Bokovoy wrote:
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-ente...
"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.
It was said "or". "low- *or* no-cost..." Do you see? Not "and", but "or".
Will I sound too unrealistic, if I say that "low-cost" would be much, much more probable?
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.
"Failed program" != "Killed program".
RH gives too few grounds to suspect it in good will, ATM.
Please file bugs/process requests and we'll see how those can be handled as a part of CentOS Stream programs.
Sure.