I’m trying to see if there is any interest in making a NixOS release “LTS”. This would mean we provide security and bug fix support above the usual year long window. The idea is to stagger this so that we don’t have to support too many releases at once. Starting with 19.09 we would do an LTS release every 4 regular releases.
I think for this to work we would need some team to form around supporting it, ideally working with vulnix team. Does anyone have strong opinions on this?
There is a high chance I would be willing to contribute to this.
Being that we don’t really have much of a backports policy and release management is kinda in the air, I think this would require several RFC changes orthogonal to this before it could really be possible. I do believe there’s demand for it with people who use NixOS on servers, but I don’t think there is so much for general users. I also think there’s some alternative life cycles that might work well in NixOS. It’s a big thing to provide, as you can’t add an LTS release to the life cycle without changing everything else, and documenting the life cycle further. A lot of good work could come out of it though. My main concern would be, I’m not sure we’re organized enough to provide this kind of support. (yet…)
Another idea, Nix is really flexible and the concept of one central software distribution could change with Flakes. Are there other things we could do with Nix to provide different life cycles to users that could blend better with their usecases?
The main issue i can see from trying to backport to other release channels, is that some backports rely on a host of other non-obvious changes which are hard to track down.
maybe if we had infrastructure in place to automatically backport important changes after a round of testing (like nix-review + nixos tests), then there wouldn’t be so much divide between teh channels
Just trying to throw my two cents: Would it perhaps make sense to start with specifically marking a small subset of packages and services to be considered for updation under such a release? And there could be a warning (and an easy to way to list) when such a package not-so is installed? Kind of like a nix-20.04-secure which only has packages which have a ‘lts-eligible’ in their meta? Throwing the net too wide only either pressures maintainers or ends up with users disappointed, and insecure. I may use NixOS-lts on server and if this is somehow public knowledge, I’m a sitting duck for all the vulnerabilities public but not fixed in the repo.
EDIT: secure and small could even be the same thing with small building from source and secure refusing to build/install at all. With the nix-flakes model, perhaps there would be an lts-date: DATE, not just lts-eligibility: BOOL? Dates may not be in sync but if you’re using multiple flakes, that’s your responsibility, to worry about in advance (there would be a warning service for upcoming lts expiry)
Nitpick: so far the period has been more like 7-8 months, although very important vulnerabilities tend to be fixed even beyond that.
I believe the most important question is (to gather those) who would do the work. Doing security fixes takes quite a lot of work, at least distro-wide, and the amount increases with the packages aging. I can’t say we catch up perfectly even on master where we can typically afford to simply update.
Restricting to a subset of packages might work, though there’s a risk that different people will desire different sets… but it could be like maintainership – a list of packages/closures with promise of being CVE-free, each promised by particular person/people.
Flakes favor pinning, which IMHO increases the risk of keeping security bugs (longer), but I can’t say I know how the practice will turn out exactly.
Selfish bump 
…
It’s been a recurring topic to have an RFC specifying core, extended, … package sets. A bit like how we have the platform supports tiers RFC. So, if you want to have a NixOS LTS I suggest to start there. As @vcunat said, then the hardest part is actually finding people who want to do this work.