Hey Andreas, Andreas Enge <andr...@enge.fr> writes: > Apparently they do not work with feature or team branches, as we had > decided to do during Guix Days 2024, but instead all commits go to a > separate staging branch, which is continually built.
This isn't quite correct. nixpkgs development almost always targets the master branch directly, the exception is changes that cause a large number of packages (500+) to rebuilt, which target 'staging'. Occasionally the current 'staging' branch is merged into 'staging-next', on which CI triggers and builds all packages. This is where regressions can be fixed etc. Once this is completed, 'staging-next' is merged to 'master' and the cycle repeats. This has multiple effects: 1. The amount of substitutes missing on master is (intended to be) restricted this way, but in practice for rolling-release users it is still better for nixos-unstable CI jobs to catch up. 2. It gives some control for the people managing the stable releases, making it possible to e.g. restrict the merging of large-scale changes during the "zero hydra failure" time period before a release, when build stability is the main goal. For the pre-release schedule there's some documentation: https://nixos.github.io/release-wiki/Release-Process.html > If not, the commits are dropped, and the people who submitted them > need to get back to square zero and submit repaired patches for the > next round. Unless something changed a lot it's not quite this strict. You can send followup PRs to 'staging' to fix problems. Or you can revert changes. > I am not exactly sure how "continuous" integration works; I suppose it > is more "discrete", in the sense that the branch is built through > once, and after that they jump to the next iteration. Yes, this is essentially correct. There's also some CI running on pull requests before they're even merged attempting to build affected packages. > As I understood it, there is one (!) person responsible for accepting or > rejecting the packages into master, in some kind of BDFL role... No. There's a large number of people who have commit bits. Proven contributors can be vouched for and get the commit bit. There's been occasional "incidents" about people with commit bits merging updates to their own packages which ended up breaking things, and I believe commit bits have also been revoked before for this reason. > What do you think? I think getting changes into master as fast as possible should be the goal, with minimal detours through other branches. This works well for Nix, and it works well for other monorepo-focused organisations (Google being the most notable one here). Batching changes in feature branches and merging them occasionally raises the risk of individual issues blocking the whole thing. It is a strange way of working to me. Another thing, and disclaimer - I don't know how Guix CI works yet, is that it is useful for people to be able to pick a commit (not necessarily the HEAD of master) which is guaranteed to be have some minimum viable set of substitutes available. In NixOS, these are the nixpkgs-unstable (smaller) and nixos-unstable (larger) branches, which are updated as CI gets around to building commits from master: https://status.nixos.org/ //V
