Nixpkgs: Please, update `nixos-unstable` channel, if it is possible - more frequently, so contributors can test and contribute

[Anton-Latukha]

Describe the bug

I am for a long time can not update on the nixos-unstable, last one there was keepass inconsistent patching blocker, but I and other contributor addressed it properly.

nixos-unstable last updated a week ago (https://status.nixos.org/), writing basically because I wait for a release to be able to close the other Report. I am waiting from July 3 to test it and close its according Report. Since one should be careful with stash of all secrets, I am waiting on the properly consolidated nixos-unstable update to arrive.

nixpkgs-unstable was released recently, and nixos-unstable passed tests successfully recently: https://hydra.nixos.org/job/nixos/trunk-combined/tested.
Me, waiting July 3 merges not hit the channel, IDK how much checkout is older, and so contributors wait.

Expected behavior

Be able to update on nixos-unstable. I couldn't switch the revision of NixOS for quite some time.

Metadata

 - system: `"x86_64-linux"`
 - host os: `Linux 5.4.20, NixOS, 20.09pre214209.f098b0dd2cd (Nightingale)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.3`
 - channels(root): `"nixos-20.09pre228622.029a5de0839, unstable-20.09pre226148.0f5ce2fac0c, nixpkgs-20.09pre226586.571212eb839"`
 - channels(user): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[Anton-Latukha]

Reopening, since nixos-channels does not getting-in reports, so report belongs here.

[veprbl]

I believe, the channel should update soon.

[andersk]

It seems that recently nixos-unstable being blocked for weeks at a time has been the rule rather than the exception. While it’s tempting to dismiss this as a combination of unrelated bugs, maybe there’s something more fundamental we could do to reduce the impact of such bugs or facilitate faster fixes? For example, what if Hydra did an automatic git bisect to locate channel-blocking regressions and filed an issue cc-ing the appropriate maintainers?

[domenkozar]

status.nixos.org is broken, channels are being updated: https://channels.nixos.org/

[veprbl]

status.nixos.org is broken, channels are being updated: https://channels.nixos.org/

It was accurate few hours ago.

The channel, indeed, advanced now. Let’s close.

[Anton-Latukha]

Why close a report when the topic of the Report was not addressed in any way, shape, or form?

---

nixos-unstable was last updated 8 days ago, and it was broken for me. I am monitoring for PR to arrive in the update from June 3. And indeed https://github.com/NixOS/nixpkgs/issues/90384#issuecomment-643812722, I could not update for several months, but I receded stating the fact in favor to be respectful and polite and a good citizen.

---

Why not to release the "stable" build that passed CI checks and adhere to the official way of releasing nixos-unstable? But instead, favor newer broken CI builds and close the Report of contributor on the ground that self upstream CI builds are broken, while this Report tries to address that, and points that there was a checkout that allows releasing nixos-unstable.

---

Isn't the Hydra CI builds advance every 3-4 hours. If we to close the Reports on that ground as in https://github.com/NixOS/nixpkgs/issues/90384#issuecomment-643833802 - we can close all Reports then, since all channels advanced since Reports were open.

Seems like the week is a pretty reasonable timespan to try to make at least one release of nixos-unstable. Isn't {nixpkgs,nixos}-unstable are channels where the active community lives.

Isn't it is possible to make a checkout of the working build into nixos-channels for nixos-unstable. Isn't the definition of the nixos-unstable is it is a checkout of nixpkgs-unstable that passed a determined bunch of CI tests for it to be promoted to nixos-unstable.

Have I missed some logic?

---

I know Hydra is always busy, but isn't a half of active community lives on the nixos-unstable? And isn't the definition of active community that it should follow the active development to be able to test everything and contribute?

Seems like not releasing nixos-unstable only results in less testing and so more bugs and broken builds accumulate and maintainers would need to work much more forming stable release, because nixos-unstable were not frequent and so the community was put frozen and so could not follow the process, test, debug, cooperate and maintain the ecosystem.

[vcunat]

Why close a report when the topic of the Report was not addressed in any way, shape, or form?

The report (and title at that point) was about channel not being updated. That had been fixed.

[vcunat]

Passing tests isn't the only condition. Also all builds have to finish, which often takes more time (various non-critical aarch64 builds/tests, etc.).

See HowOldIs and the NixOS Wiki for information on how channel updates progress.

EDIT: and for big nixos-unstable, the evaluation runs once per 24h... because all that CI is quite expensive (mainly the large number of VM tests, and ISOs are space-expensive for the CDN).

[Anton-Latukha]

I know that there is an overloading play on terms channel and update. nixos-unstable is a channel, for contributor it is important that it sometimes updates to some master checkout, isn't it? Isn't that process is _"updating nixos-unstable channel to newer master checkout"_?

Ok. Please, there should be some minimal timely manner for nixos-unstable, I wait for changes to hit from July 3d, it soon be two weeks of just solid waiting and monitoring. It is not only my experience, we just do not know when our results arrive to us.

There is just no information anywhere on how long it declared and promised to take.

If contributors at least knew the least frequency of the trickle-down of master into nixos-unstable that the process and maintainers keep - week, two, three, month, 2 months, they would know how long what they did in master can be awaited to arrive to them.

[vcunat]

I don't know... more Hydra power would help (more frequent evaluations, faster builds of any fixes), and more people watching the channel-critical jobs and doing whatever they need to fix them (sometimes issues are not even related to any nixpkgs commits). I do watch the jobs relatively frequently, but my paid work isn't really related to any Nix* stuff, so for me it's just free time and I certainly can't seriously promise anything... not sure if someone else would be willing to provide such guarantees to the community for free :-)

Yes, maybe some other technical measures could be implemented to decrease the longest waits (I'm not sure), but first... it holds the same – someone has to implement them.

BTW, anyone can try newer stuff _easily_ without waiting for channels (or use the small channels) and still get all binaries that are available at that time, but I'll assume all readers of this thread already know about that...

[Anton-Latukha]

I know.

I do not demand or expect anything really, I and other contributors just need to know some standard norm of the longer bound of the timeframe the master things arrive into nixos-unstable that maintainers call "at least it hit our norm" , so contributors know when to check and await it.

Can we have some arbitrary big time period, like nixos-unstable is expected in 3 weeks or month.

Maybe someone or I can from nixos-channels figure and contribute the documentation on the deviation bound of the frequency of nixos-unstable syncs to master checkout, going from what is real data on that. I can document that on the Wiki, but it also should be kind of at least an upstream norm before the contributor can morally put such statements to the wiki.

Thank you @vcunat, I know you are moving things in Nixpkgs already for a several years at the least.

[lheckemann]

Note also the nixos-unstable-small channel, which does update more frequently by having a smaller test set. Maybe that's better suited for your use case?