| 6 Dec 2025 |
 whispers (it/fae) | thanks! | 15:56:09 |
| 7 Dec 2025 |
|  Alex Epelde joined the room. | 18:35:11 |
| Alex Epelde left the room. | 18:37:13 |
| Alex Epelde joined the room. | 18:37:26 |
|  Robert Evans joined the room. | 18:46:49 |
| Robert Evans set a profile picture. | 19:02:49 |
| 8 Dec 2025 |
|  @hhr2020:mozilla.org joined the room. | 01:53:07 |
| @hhr2020:mozilla.org left the room. | 01:53:49 |
|  raboof joined the room. | 15:46:37 |
| raboof | https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#staging describes staging is 'regularly' merged into staging-next. I'm curious what the 'criteria' for that are - I suppose you generally don't pull in more changes from staging when staging-next is close to be mergable to master? | 16:05:07 |
 emily | we do not pull in any until it merges | 16:05:57 |
| emily | (unless we have to) | 16:06:03 |
| emily | staging-next is there so that rebuilds sent to staging don't throw away builds in the cycle | 16:06:31 |
| emily | (or we'd have to "freeze" staging periodically which AIUI was done in the old days) | 16:07:05 |
 Grimmauld (any/all) | only viable if the preople running staging can reasonably keep track of all open mass rebuild PRs, those days are long over | 16:07:59 |
| raboof | right so essentially only when staging-next merges into master, staging becomes the 'new staging-next'? | 16:08:29 |
| emily | I get the impression it was more yelling at people for merging into staging at the wrong time | 16:08:32 |
| emily | yes (except not really as we rotate through the stable release branches too) | 16:08:53 |
| emily | usually we do unstable, stable, unstable, etc. | 16:09:02 |
| emily | with a day or two in between for the channel to catch up post-merge | 16:09:16 |
| raboof | gotcha, so in the mean time there 'is no' staging-next while you're working on staging-next-xx | 16:12:38 |
| Grimmauld (any/all) | the branch technically never goes away, it is still used as an intermediate for periodic merges, but it isn't really in active use in that time, yes | 16:14:16 |
| 9 Dec 2025 |
 uep | Ignoring merges from master for simplicity:
- things go into
staging all the time.. and wait there to batch up rebuilds
staging merges into staging-next and rebuilds run, periodicallystaging-next merges into master, via a manual PR at suitable timestaging-next doesn't go away, but has nothing "interesting" in it until the next time staging merges into it.
| 03:02:05 |
| uep | * Ignoring merges from master for simplicity:
- things go into
staging all the time.. and wait there to batch up rebuilds
staging merges into staging-next and rebuilds run, periodicallystaging-next merges into master, via a manual PR at suitable timestaging-next doesn't go away, but has nothing "interesting" / new in it until the next time staging merges into it, it's basically a point in time on master for a while
| 03:03:35 |
| uep | the automated merges go from master to `staging-next | 04:09:17 |
| uep | * the automated merges go from master to staging-next to staging (picking up the fixes in staging-next along the way) to keep both branches up to date with all the leaf-package/small-rebuilds changes | 04:10:05 |
| uep | and so those changes meet the mass-rebuild deep-dependency changes waiting in staging/next, and can sometimes be broken by them there | 04:11:19 |
|  @adam:robins.wtf changed their profile picture. | 17:25:11 |
| @adam:robins.wtf changed their profile picture. | 17:48:31 |
| 10 Dec 2025 |
| @adam:robins.wtf changed their profile picture. | 14:49:53 |
