Maintainers needed for merging staging/staging-next branches

Development
1

Nixpkgs has 3 active development branches, master, staging-next and staging. The rate at which changes are merged is high and still seems to be increasing. It is important to merge master into staging-next and staging-next into staging regularly to ensure those branches are up to date and to reduce the amount of merge conflicts. What is regularly? Approximately daily.

For a while now it’s been mostly @vcunat and me that have been merging these branches. I would like to ask other @nixpkgs-committers that are interested in this to help out with it.

1 Like
2

IMO merging itself usually isn’t difficult, but watching for large regressions (in master..staging-next) and resolving them can be quite time-consuming, especially as mass rebuilds tend to trigger various transient failures.

3

I am willing to lend a hand. However, the whole process is still somewhat unclear to me.

From the RFC, I got the idea that the process works something like this:

digraph {
    "small changes" [shape=none]
    "mass-rebuilds and other large changes" [shape=none]
    "critical security fixes" [shape=none]
    snfixes [label="fixes for staging-next Hydra jobset"] [shape=none] [fontcolor="#A3427C"]

    "small changes" -> master
    "mass-rebuilds and other large changes" -> staging
    "critical security fixes" -> master
    snfixes -> "staging-next" [color="#A3427C"] [fontcolor="#A3427C"] [label="2. [while Hydra jobset is failing]\npush fixes\n(during stabilisation)"]

    "staging" -> "staging-next" [color="#E85EB0"] [label="1. merge branch\n+ open staging-next→master PR\n(begins stabilisation)"] [fontcolor="#E85EB0"]
    "staging-next" -> master [color="#6B2B51"] [label="3. [if jobset succeeds]\nmerge the PR\n(concludes stabilisation phase)"] [fontcolor="#6B2B51"]

    master -> staging [color="#5F5EE8"] [label="any time"] [fontcolor="#5F5EE8"]
}

preview

However, the OP mentions master → staging-next and staging-next → staging. How does that fit into the diagram? Do we need two more blue arrows?

1 Like
4

master is typically not merged directly into staging, but through staging-next. That way, staging will contain all commits that are in master, staging-next and staging.

5

I think the most compelling reason is that the staging → staging-next step is quite infrequent – a few times a month, usually. And you do need to sync staging-next with master more often, for conflict resolution and to pull in some rebuilds (conflicts would have to be resolved twice due to that blocked edge – once when merging master → staging and once for staging-next → master).