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.