| 15 Feb 2026 |
 emily | this is also a lot more auditable than our current manual merges because we can treat the staging commits like the cherry-pick CI and flag them up when they're doing something non-automatic | 18:04:34 |
 Vladimír Čunát |
should probably conditionalize and revert on staging
Conditionalized.
| 18:07:43 |
| Vladimír Čunát | *
[git PR] should probably conditionalize and revert on staging
Conditionalized.
| 18:07:56 |
| Vladimír Čunát | [radical] I see (on a very high level at least). At a glance I'm a bit worried that some changes would be more difficult to write. And adding conditionals can cause unpleasant diffs because of force-formatting. | 18:12:53 |
| Vladimír Čunát | Nice for simple version bumps probably, though. | 18:13:48 |
 Grimmauld (any/all) | compression libs do get quite some CVEs for random shit. We call our package sources "trusted", because they are pinned by a hash - a luxury we can not afford before calculating the hash. If hashing itself is an unsafe operation, then things are wrong. And thus i have my doubts about pinned zlib... | 18:15:40 |
 K900 | I mean | 18:16:19 |
| K900 | This is what Yarn upstream does | 18:16:22 |
| K900 | The only other option is regenerate all lockfiles | 18:16:28 |
| K900 | But sigh | 18:16:32 |
| Vladimír Čunát | At that point we just mark these fetches as insecure? 😅 | 18:17:37 |
| Vladimír Čunát | * 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 |
| Vladimír Čunát | (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 |
| Vladimír Čunát | 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 |
| emily | (but it punts on helping with the conditionalization dance except insofar as it makes it easier to land the conditional and the clean-up in the same PR without one getting forgotten) | 18:31:01 |
| emily | also with the feature flags variant we could still have the "controbutor didn't realize this needs staging, let's retarget with a couple clicks" convenience by having CI detect PRs targeting a staging branch, automatically push the generated staging commit, and retarget back to master | 18:33:34 |
| emily | which also means that if you're doing a simple non-conflicting staging change you don't need to run any script locally at all and can just send a PR to staging as you do now | 18:34:02 |
| emily | the script doesn't have to be perfect because it's just a convenience and doesn't have to be in the trusted code base, it can get away with just handling the common cases | 18:35:18 |
| 16 Feb 2026 |
|  zimward changed their display name from zimward to zim. | 13:49:45 |
| zimward changed their display name from zim to zimward. | 13:50:49 |
|  pneumatic changed their profile picture. | 15:18:01 |
