2 ms·

> For example, the side-bar of the interface doesn't load properly quite often, and you need to click on "reload" button few times to get it to show up... Well

> For example, the side-bar of the interface doesn't load properly quite often, and you need to click on "reload" button few times to get it to show up... Well, what can you do? - Yes. Nothing. So... go debug the JupyterLab code. Or open a bug with upstream. Or talk to their support. Or rant on Twitter to try and mobilize upstream to fix their shit. There's not nothing to be done, that's defeatist nonsense. In the meantime, in your codebase, mock the stuff you can't control and move on. That's why mocks exist, so that your test suite can be fast and deterministic even when speed and determinism are otherwise systematically difficult to achieve. > hardware 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. You look over the test results, make a manual decision what needs to be retested, and just retest that before deploying. In dev, hopefully you have some kind of emulated device to develop against, in which case, the point is moot.

crabbone 3y ago
> 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.

crabbone 3y ago

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