> So... go debug the JupyterLab code. Or open a bug with upstream. Users want this particular version of JupyterLab. Not the one in the future which might get

> So... go debug the JupyterLab code. Or open a bug with upstream. Users want this particular version of JupyterLab. Not the one in the future which might get fixed. In the case of JupyterLab, I can maybe try to patch it and promise users that "it's the same but with the patch", and maybe they'll take it, but maybe not, because their IT vetoed only version X, and my X+patch is not exactly X. But, it could as well be closed-source third-party software (for example, we help users to install PBSPro, EG and LSF workload managers). It's illegal to debug them or to patch them... > Hardware is a totally different ballgame. And not one where you're trying to come up with SLOs for flakiness in a CI system. You don't continuously deploy hardware. So much nonsense here... * CI isn't about deployment. * Yes, when I worked for a hardware company, we continuously tested integration between hardware components. * Why wouldn't the concept of SLOs apply here? You say it without giving any explanation.