Comment by zie
3 days ago
If your software is in such heavy development that you need changes all the time, it should never be in a stable distro to begin with, it's not stable code.
Overall(last I checked), the testing is roughly equal between the stable distro's(Debian/Ubuntu/etc) and NixOS. The difference is stable distro's back-port bug-fixes. NixOS rarely does, since their release cycle is only 6 months long.
> * Alienating you from upstream: why contribute upstream if you'll only benefit from them in 2 years.
I contribute upstream, regardless of if I'm running NixOS, Debian Stable or Windows. It makes no difference to me which OS I'm running when a bug shows up. If I find a bug in X package, I go fix X package. Sure I also fix it locally in my running instance(s), but that's my problem, regardless of which OS I'm running.
> To mitigate breakages we should be aiming for better test coverage, at various build levels: class, package, program, system.
Yes, yes we should. Most software has a terrible testing story. There are very few pieces of software with robust testing. SQLite is one such. One could probably name a handful of others, but after that the list gets really hard to add to.
> If your software is in such heavy development that you need changes all the time, it should never be in a stable distro to begin with, it's not stable code.
Stable code by this definition experiences some stagnation. But the cost of stagnation is worth it for the stability. That's LTS.
Slowly, we'll build enough checks that we can achieve frequent change and still be stable. This is partially here, and "unevenly distributed".
> Overall(last I checked), the testing is roughly equal between the stable distro's(Debian/Ubuntu/etc) and NixOS. The difference is stable distro's back-port bug-fixes. NixOS rarely does, since their release cycle is only 6 months long.
NixOS has system-wide tests that run on PRs, and go green if they pass. E.g. upgrade OpenSSH will trigger a suite of VMs to start, each running OpenSSH in different configurations, and checking they work as expected. These run automatically, are visible to contributors/reviewers, and take O(minutes) to complete. They run on automated backport PRs too.
> contribute upstream, regardless of if I'm running NixOS, Debian Stable or Windows. It makes no difference to me which OS I'm running when a bug shows up. If I find a bug in X package, I go fix X package. Sure I also fix it locally in my running instance(s), but that's my problem, regardless of which OS I'm running.
Bravo. But I don't think it's controversial to suggest that, on average, the closer a person is to upstream version, the more likely they will be to have the motivation and success in making a contribution that meets theirs and and upstream's needs.
> NixOS has system-wide tests that run on PRs, and go green if they pass. E.g. upgrade OpenSSH will trigger a suite of VMs to start, each running OpenSSH in different configurations, and checking they work as expected. These run automatically, are visible to contributors/reviewers, and take O(minutes) to complete. They run on automated backport PRs too.
That concept is not new to stable distro's either. Though the OpenSSH package doesn't do that level of testing in Debian, their tests are here: https://salsa.debian.org/ssh-team/openssh/-/tree/master/debi...
> Bravo. But I don't think it's controversial to suggest that, on average, the closer a person is to upstream version, the more likely they will be to have the motivation and success in making a contribution that works you and upstream.
This mindset makes no sense to me. A bug is a bug is a bug.
Those Debian tests are great. Good coverage, run on PRs. A little obtuse in parts, but still great.
1 reply →