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

On 12/29/20 12:16 PM, Nico Kadel-Garcia wrote:
> [...] The resistance to
> point releases is understandable, especially to people trained on
> "continuous integration, continuous development". But many businesses
> and developers find continuous release unsafe and destabilizing,
> generating constant uncertainty about their environment.

Sure they do, because it's over-hyped and it doesn't work in practice - 
CI is necessary, but not sufficient. Big car manufacturers here really 
follow best practices, every commit having to pass CI/CD to be 
integrated (thousands of tests in R&D), there are additional test 
departments, years of manual testing and many thousands of km of test 
drives made by human test drivers, and cars still have plenty of bugs on 
release. Errors are then corrected in production, there is also at least 
a facelift that corrects additional bugs, and when the car is 
discontinued, there are still bugs, from the rear camera occasionally 
getting confused (displaying the warning messages, but an unfocused or 
black image - turning the motor off and waiting 30s fixes that), the 
smart key only opening the trunk, but not the doors after 3-4 days (open 
all door windows completely to reset the smart key system), to the car 
suddenly engaging emergency braking while driving, seeing an obstacle or 
person where there isn't any. The latter is really life-threatening on 
the Autobahn, and I found out a smaller model from the same manufacturer 
is also affected by that, so it's unlikely to be a sensor malfunction on 
just one car.

I'm somewhat skeptical the 4 hours of automated CI that someone from Red 
Hat mentioned are going to be enough, without extensive human testing - 
but Chris Wright wrote that Stream is not suitable for production use 
like RHEL is.

> EPEL is an example of the problem. Many critical system components,
> such as python modules, nagios, and until very recently ansible, were
> available in EPEL as leading edge components only, without easy access
> to the previous releases. It's maddening. If you have other components
> that rely on stable bits, well, it's been awkward.

I had a case of an updated dependency of a dependency that relied 
implicitly on the slightly changed semantics of asyncio in Python 3.3.5, 
so it didn't really work correctly on distro-provided 3.3.1, without any 
errors or warnings (the method existed, but behaved a bit differently), 
sometimes "losing" requests. When you have tens or thousands of 
dependencies, constantly updated from EPEL or PyPI, such subtle bugs 
will slip through. If there is any LTS distro maintaining stable 
packages, only fixing bugs, I think it's much safer to use that instead 
of trying to update everything yourself.