On Sunday, January 31, 2021 7:14 AM, Peter Meier peter.meier@immerda.ch wrote:
I can't use CentOS Stream - it is beta quality and has critical bugs. For example: https://bugzilla.redhat.com/show_bug.cgi?id=1913806 This bug is critical for me, because I use systemd-nspawn containers for production. I will continue to use CentOS Stream in the future, but only as the beta-tester, to see what new will be in the future minor release of Oracle Linux / Alma Linux / Rocky Linux.
[...]
And as a Stream user and contributor you can also add your use case to t_functional which in the end becomes gating for Stream. So you avoid future regression for your use case, although it is even not officially supported.
How? When?
I still see no method to submit a pull request against the official CI/CD t_function sets. I also have not seen an ETA to being able to do so.
Where is the example code of existing t_function sets?
Where is the style/coding guide that must be followed to get new t_functions accept?
But calling Stream Beta just because of a regression in a unsupported future?
I find your logic hard to follow for this specific "unsupported feature."
The prefer way of using modern mock is use of nspawn. The prefer method of using mock with koji uses nspawn.
To be more specific, as far as I can tell I can take CentOS 8.0 as the basis for a koji environment and use it with mock using nspawn to build CentOS 8.0 updates and CentOS 8.1 packages.
I can then update the environment to CentOS 8.1 and still use it to build CentOS 8.1 updates and CentOS 8.2 packages.
I can then update the environment to CentOS 8.2 and still use it to build CentOS 8.2 updates and CentOS 8.3 packages.
I can then update the environment to CentOS 8.3 and still use it to build CentOS 8.3 updates.
If I then update to build servers to Stream, there is a problem with that foundational component that was previously working on the build servers.
The idea that RHEL team would treat this as unsupported and release it regardless as part of RHEL 8.4 does not sound correct to me.
The idea that clones would also break their own koji environment and never provide support to get them working again also does not sound correct to me. At some point the clones would release some sort of "plus" kernel with a fix to address their own build environments and that of their users.
For a regression in a component this valuable to modern koji setups to exist does indicate to me that Stream is still, as of today, in a beta/rawhide like state.
As you pointed out, we should expect CI/CD to address this issue. But that will be over some length of **time** and December 31, 2021 is a *HARD* target.
It would just be really nice to also have a hard deadline for being able to contribute to the CI/CD test as well. I foresee next January being the month when several users will give Stream a single chance to pass or fail on their own criteria. Several might be even more strict than we are being today. I want to have Stream in a condition that allows it to put it's best foot forward by that date.
Karsten Wade implied CI/CD will make Stream usable for 95% of current CentOS users. I would like to believe that but what I am seeing still has *ALOT* of work to do. And there does not seem to be a hard deadline for when the community can contribute to CI/CD, only a hard deadline for CentOS 8.
We are now 20% of the way between November 11, 2020 and December 31, 2021. Even if you feel calling Stream today "beta" is unfair, are you really willing to say that we are 20% or more of the way done to getting Stream to the best possible state to encourage adoption by 95% of existing CentOS users?
To be clear, I am not trying to trash-talk Stream. Rather I see a miscommunication in where we are today and how/when we are going to move forward. Step one of fixing a problem is admitting you have one.