Request to get a staging fix in before 26.05 release

Development NixOS Releases
1

Could someone with a Commit bit get PR#523568 merged before 26.05 is declared released. Ideally Hydra would be able to get it into a build before then (fixes a few failing packages).

Thanks

2

That’s not possible. Each staging* cycle takes about two weeks, and we have multiple candidates now (25.11, 26.05 and for master).

3

I mean, the change will get into 26.05 later, provided that someone does merge it.

1 Like
4

Well I mean it could be merged in now (has to be manually done in any case, the Release workflow does allow this). However, as it seems that no initiative is likely to be taken on this, I’ll just mark this release broken and change to running releases off master.

EDIT: Clarity (meant master/main not Unstable-channel)

5

I do question the “beta” status of the 26.05 release, in this stage though. If no changes are accepted past that point, why delay the release another week? The first full build off Hydra may as well be considered the “final/complete” release…

6

What @vcunat is saying is that even if this gets merged now, the change will not get into the initial release of 26.05 because there’s simply not enough time for new staging changes to make it. 26.05 being beta cannot change how the staging cycle works, and it’s not a matter of whether the change should be in 26.05, but rather whether it can make it into the initial release.

2 Likes
7

My initial point remains then, if nothing can change the state of 26.05 beta, why refer to it as beta (and similarly declare the actual release to be 5 days away from it)? If its considered immutable, then 5 days might as well be saved and the release declared then.

However, I’m not sure I follow why this change being merged now couldn’t be in the release [channel]. Just looking at the latest Hydra build, I see changes still getting merged in/part of this release (for e.g. PR#523618, (not trying to call out this PR, just using it as an example))?

EDIT: Nevermind, the quoted. These are non-staging (i.e. non-mass-rebuild) changes. I understand what your saying now @figsoda(emphasis on staging).