This aims to implement a new merging strategy for the nixpkgs repo which will reduce the amount of time that nixpkgs-unstable and nixos-unstable channels are blocked due to build/test failures.
When the channels are failing it presents a number of issues. But reducing the amount of time that the channels are blocked we will improve the following scenarios.
Security updates are very difficult to push. You need to roll back master or make a special cherry-pick build to avoid the broken changes.
Regular package updates are blocked which is annoying to maintainers and users.
Contributors who base their changes off of the master branch(which is the default) may experience brokenness. These users then have to manually rebase their work onto a working commit.
This is implemented we hope to see the following changes:
The nixpkgs-unstable and nixos-unstable channels are passing more often.
Security updates land in the *-unstable channels quicker.
More contributors submit and continue to submit PRs.
No less maintainers submitting PRs(except maybe for PRs obsoleted by the previous point)
Requirements
This policy must not increase the difficulty of maintaining packages, especially the core packages.
This policy must not increase Nix Hydra resource usage. Nix Hydra is effectively fixed-resource so this needs to improve the situation given the same amount of resources.
Difficulties
Some derivations are flaky, they have sporadic failures. This means that even passing releases of nixpkgs may have“bad” derivations included. Furthermore due to Hydra caching these failures will not appear often.
Derivations can break due to external changes, such as source or patch URLs dropping off the internet. This will manifest as a breakage the next time that a package is broken even though the change that detected the breakage is in no way responsible for the failure.
Some derivations can only be built on CPUs with specific feature sets. Hydra does not support scheduling these builds on machines that are capable which is a known sort of flakiness.[source]
Core libraries and tools are depended on by many, many packages and just about any update will result in some dependent breakages. We need to make these changes and the dependency maintainers often don’t have the resources, or knowledge to fix the breakages.
Objective
Requirements
Difficulties