Maybe the underlying issue is just branching convention. Clearly the general community has gotten so used to just treating unstable as a stable target that the branch has become unusable for this type of development in practice.
Maybe the backport policy could be relaxed so that more packages end up being bleeding edge. I’ve certainly heard of users who use unstable purely to keep electron packages up-to-date, and there are many who just want to use the latest versions available of all packages for no particular reason.
Maybe there could be a nixos-indev where all development happens, a nixos-unstable which receives all package bumps, but only compatible changes to modules (if package bumps break modules between releases users have to deal with this downstream), and a nixos-<version> with stability guarantees for packages and modules.
It seems to me that most complaints are about breaking changes to modules, anyway, breakage in third party software is simply less impactful because it usually doesn’t impact the system as a whole - more fundamental packages just have better backwards compatibility and more reasonable release strategies, so breakage in e.g. systemd is exceedingly rare. Churn in other software is also inherently smaller than in nixpkgs. Plus, users don’t usually see those versions as much, so they’re less likely to run nixos-unstable for, say, a systemd bump.
Maybe we could have another channel (e.g. rolling)? Everything would first go into unstable and then maybe 1 week later into rolling. If enough people are willing to still use unstable we could catch breaking changes early and fix or document them.
The reason I think a branch with different backport semantics is necessary is that you’d basically just end up with a copy of unstable with your approach.
Most users won’t be updating daily, so for a lot of issues you’d see practically no change with a short update cycle. Make the update cycle longer, and now we just have more frequent NixOS releases and the associated overhead and effort, for ultimately no gain because users are still going to pick unstable since the longer cycles are too long.
Having beta testers for a branch also doesn’t really solve much here; the complaint is not that bugs happen, it is that intended changes happen when users don’t expect them (i.e., breakage != bug). People on unstable - assuming they’re making an informed decision - have already opted in to being the beta testers you suggest, it just turns out that they don’t like being such in practice.
I believe that breaking changes would be considered fine as long as people are aware of and agree to the contract of the backports that hit their update channel; NixOS’ existing options for this just apparently fail to cover some use case.
I think it’s worth figuring out why so many people use unstable, and offer a useful solution to whatever use case drives that.
I’m not sure whether I’m normal (!) but I use stable when a new release comes out, and at some point in the six months I switch to unstable to save myself the hassle of cherry-picking shiny new things. I know how to cherry-pick from unstable and if unstable ever gets less stable I’ll do that and still be happy.
Perhaps a partial solution here is to look to what arch linux and home manager do with news. People perhaps would be happier beta testers if when they had taken this change they had seen the following when running nixos-rebuild
Breaking changes since you last pulled:
- pam blah blah i3lock, please check the following
[Y] to acknowledge
rather than just eating the failure silently. I agree that some of the suggestions here might have turned this change into an eval failure, but perhaps a changes feed delivered inline could be complimentary to that, and I don’t think a massive amount of work based on what hm does.
EDIT: we could also retire the discourse thread, which I would see as a win. No one should need to be here to know what they need to do to keep their computer functioning.
I feel like we might want to create a new topic about this. This particular breaking change doesn’t affect me but I am interested in how we handle breaking changes in general. As mentioned before, this does seem like a change management problem more than a development problem. And everyone’s ideas seem to largely fall under:
new or changed communication channels
adding or changing releases (e.g. unstable, 23.11, “rolling”)
policy for documenting breaking changes
automation to alert about breaking changes.
changes in git practices
versioning
That’s quite a bit to chew on, maybe a working group is in order?
Would be a good idea to be honest, as the thread was split out from a separate thread without the full context, and the initial goal was just to voice frustration at the different (and admittedly declining) standards nixpkgs-unstable/nixos-unstable have been held to recently.
And honestly, I’m pleasantly surprised to see how productive and positive the discussion around this has been, so I’d assume it could potentially actually lead to something (e.g. an RFC that perhaps outlines some of the points you bring up, and how unstable the unstable branch should really be, etc.).
If nothing else, getting an idea of how contributors view this topic would probably help create some clarifications around what can actually be expected, and hopefully, re-evaluate whether or not that is acceptable.
It would also be nice to conduct discussions of subtopics in a way where everything doesn’t get cluttered together like in this single thread.
This seems like an excellent idea. I think nixpkgs contributors have a very specific idea of what “breaking” means, and this has historically not been communicated to users well, nor has it ever really been considered whether the definition is actually helpful to a user in practice, especially if applied widely to all packages and modules.
And clearly, expectations of stability and naming of the unstable branch need to be reevaluated.
As this affects literally every stakeholder, a WG where no particular group is under-represented would help give a balanced discussion. There might even be some longer-term work that falls out of this to try and help with policy enforcement beyond code review.
I think threads like this have a tendency to not give contributors as much of a voice as they should have, since they are a minority in this context and ultimately the only group that directly “benefit” from breaking changes - keep in mind that lower barriers to nixpkgs contributions ultimately benefit everyone, so even if you don’t like this aspect, reasoning about it must include the voice of the group that needs breaking changes to stay sane.
I think there is quite a lot of optimism in that phrase, implying that there is only a single very specific idea shared among all the contributors… I think there are multiple specific ideas (incompatible ones), each communicated to some but all other contributors.
Just in this thread we have different opinions from contributors about tradeoffs related to different kinds of breaking changes…
I must have not communicated my point then. If someone else merges it constitutes a signoff from another committer. Otherwise it just opens up the opportunity for someone to just get one approval and merge while avoiding feedback. Not saying that was the intent here, but it is substantively different from having someone else merge.
If we have 300 committers excluding a PR author and none of them feel confident in the change to merge it, it probably shouldn’t go in.
This is a misleading reference to a number, as most of them don’t feel anything about the change as they haven’t noticed it (and hopefully won’t notice it when it’s merged).
… and the useful question is what easy to define signs we have that a change has high enough impact to spend effort making it noticed, not how to create incentives for committers to do tit-for-tat reviews for each other.
And I suspect that confidence in evaluating a change to the core modules risks being positively correlated with using modules which are not really necessary (and believing this is the way NixOS is mostly used), so we need to define warning signs better anyway.
