What is the background of this? Is is quite noticeable that all of the signers seem to have a background of Linux on mobile phones.
I saw this happen yesterday because a package had no versions published and
documented some of its dependencies with commits regardless of their
versions.
It would be nice to have a written policy against this.
Mobile Linux is in great flux, highly fragmented and generally best practices are still under evolution.
Not surprising that they feel the need to voice it out. While I’m waiting for ghe day I can slap any random ISO and install it on my phone, we are not there yet. Desktop distribution practices are better off not shoehorned onto mobile distributions for the time being.
I’m not aware of a written policy we have, but the letter matches my understanding of what Nixpkgs is about: we try to ship the latest released version of software and we try to deliver upstream intent as best we can.
A bunch of packages in Nixpkgs do have date/git sha versions, but most of the cases I’ve seen of this involve unmaintained upstreams.
I’d be in support of an RFC that codified this more.
I feel like this statement isn’t enough. While nixpkgs is pretty good at delivering packages in a way that upstream intends I feel like we would be misleading people if we didn’t continue to state that NixOS doesn’t follow the same principle.
Without implying this is good or bad I will state that their are a number of NixOS developers who feel they are more qualified to make decisions on how an OS should run software than the upstream developers are. As someone who extensively reviews PRs which touch our module system I have seen many times upstream instructions or services ignored in favour of the module authors opinion. On the flip side of that statement many times that I have seen this happen the NixOS developer really did have a better opinion than upstream. I have merged such PRs myself.
Not to drag this too far off the original topic, but to provide a concrete example of when our software diverges from upstream please see any of our systemd services that include a ton of hardening that upstream does not. Many hardening options can significantly impact behavior of software and usually our testing includes one person saying “these hardening options worked for me 
”.
In my opinion, there should be no reason to be more lax about applying this (currently informal) policy to NixOS. The fact that e.g. overriding a systemd service is easier than patching the source code should not entitle us to be lazy and not upstream the changes – the same arguments still apply.
Often upstream is not aware there is a room for improvement because they are not systemd experts and without anybody suggesting changes, it is unlikely that something better will ever be adopted.
So I would recommend reviewers to push for upstreaming any overrides in NixOS module code that can be upstreamed. Or at least add a TODO comment to get rid of the deviations in the future.
Sometimes not unmaintained, sometimes the upstream maintains the codebase but just doesn’t do releases.
Excerpts from M R via NixOS Discourse’s message of June 7, 2022 10:27 pm:
Sometimes not unmaintained, sometimes the upstream maintains the codebase but just doesn’t do releases.
Releasing software as a cohesive collection versioned by date or atomic revision is a tradition way of doing things and we shouldn’t punish these sorts of packages with arbitrary “unstable” designations.
That said, I think unversioned libraries and programs coming from ecosystems where versioning is normal an beneficial should be marked as unstable.
In my opinion, there should be no reason to be more lax about applying this (currently informal) policy to NixOS. The fact that e.g. overriding a systemd service is easier than patching the source code should not entitle us to be lazy and not upstream the changes – the same arguments still apply.
Often upstream is not aware there is a room for improvement because they are not systemd experts and without anybody suggesting changes, it is unlikely that something better will ever be adopted.
Continuing on this comment, I would argue that NixOS (or similar systems) is in a unique position to provide for advanced systemd configuration that cannot be captured by a single static flat file and would require embedding some ad-hoc DSL upstream which creates more friction for the final package adoption in distributions.
So I believe it is difficult to “upstream” the NixOS Module lessons back beyond just communicating what is known to work in terms of hardening, ways of setting the state directories, etc.