@sh01, thanks for your PR! By analyzing the history of the files in this pull request, we identified @pSub, @civodul and @edolstra to be potential reviewers.

The test failures are all timeouts. It's extremely unlikely they were caused by this change.

Please use git cherry-pick -x so that a reference to the original is retained in the history

joachifm: Ah, thanks. Done.

This changes triggers many builds. I think I should go into staging-16.09 first.

Okay; I've switched it to the staging branch.
What's the precise process, here? Will it get merged into release-16.09 automatically after a while, or will I eventually need to follow up with another pull request for that?

@sh01 somebody will merge staging into release once the rebuild has completed

Maybe we'll need some policy discussion about staging-16.09. Currently it's disabled on Hydra and I'm personally not really convinced of its usefulness (contrary to staging).

The worst outcome is when some people push mass-rebuild stuff through a separate branch and some don't, because it's complicated and it's more work for Hydra than either of the ways (when followed by everyone).

@vcunat We've created staging-16.09 for #18522. We shouldn't use that branch too often or maybe even remove it. It was useful for that PR because we had to check for newly failing builds before pushing that change to 16.09. Most backports that yield full rebuilds for 16.09 should be pretty safe, though, so we could just push to the release branch.

Maybe it would make sense to wait for all packages (or all hydra jobset evaluations for a branch/commit) to be built before releasing a new channel version? Right now we wait for NixOS tests to succeed which is fine for master but not so much for stable because people probably don't want to compile software when they update their stable channels.

I'm confident that channels have always waited for all builds to finish (in addition to updating only if a tested job succeeds). EDIT: in my mind it's related to the fact that it was the point where binaries used to be uploaded to the binary cache, though that's fortunately done immediately after each build nowadays.

My understanding has been that staging exists to minimize disruption for people developing against master, not as a testing ground for potentially breaking changes. I personally do not develop against release, so would not mind removing staging-16.09.

The long-term fate of staging-16.09 aside, should I modify this particular pull request back to go directly into release-16.09?

Hmm, I removed staging-16.09, at least for now.