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

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, December 29, 2020 7:32 AM, Laurențiu Păncescu <lpancescu at centosproject.org> wrote:

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

I also have my doubts about how much CI will be ready enough before 2022.

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

dnf will allows enabling COPR builds for updates.  Using either Docker or KVM might be the best way to deal with fragle applications or environment requirements.  Just take a snapshot before running updates and revert as needed.