| 15 Feb 2026 |
 K900 | But sigh | 18:16:32 |
 vcunat | At that point we just mark these fetches as insecure? 😅 | 18:17:37 |
| vcunat | * At that point we just mark these fetches as vulnerable? 😅 | 18:17:45 |
 Grimmauld (any/all) | can we just delete JS? /hj | 18:18:12 |
| vcunat | (the "vulnerable" mechanism isn't able to differentiate substituted builds, unfortunately) | 18:18:30 |
 emily | they'd be the same to write | 18:19:22 |
| emily | staging and staging-next would always have the tree after cleanups for the relevant epoch | 18:19:52 |
| emily | so you just work on that branch and run the script to produce the form that goes to master as a commit on top | 18:20:26 |
| vcunat | I missed the script. See it now. | 18:20:38 |
| emily | essentially a merge of staging/-next back into master | 18:20:38 |
| emily | it'd suck to touch stuff being staged on master, but that's the thing that sucks now and the suck gets externalized to people doing manual merge :) | 18:21:16 |
 Lun | nixpkgs, now with federated suck processing technologyâ„¢ | 18:22:12 |
| emily | there's a lower-tech variant where you have no conditionals in the code but every staging/-next PR has a HEAD that merges it back into master to undo the changes, and merge queue just validates no conflicts/eval errors across the branches. that makes merging -next into master weird from a Git POV though (it would produce a nop by default because "all the changes are already merged in").
or the reverse is that if you have to do something to resolve conflicts between master and staging/-next you keep your commit based on master but add a merge commit merging it into staging/-next and the master portion of it just gets automatically backported.
those avoid any eval time machinery but abandon the property that there's one canonical tree that lets you see when stuff is in flight before you touch it. they would also interact a bit weird with the way GitHub displays merge commits and require CI to have more smarts around them
| 18:27:30 |
| emily | the latter option does have the perk that it's exactly the same merge structure we have now and just distributes the work of doing the conflicting ones to the authors of the PRs that cause the conflicts | 18:29:07 |
