| 9 Jul 2025 |
 vcunat | I can see that in some situations we could utilize possibility of manually adjusting what the channels point to. | 09:13:58 |
| vcunat | * I can see that in some situations we could utilize some possibility of manually adjusting what the channels point to. | 09:14:06 |
| vcunat | * I can see that in some situations we could utilize some possibility of (half-)manually adjusting what the channels point to. | 09:14:14 |
| vcunat | Even if the usual preconditions don't hold. | 09:14:29 |
 emily | did we make a decision about Git | 12:45:11 |
| vcunat | I don't think we did. | 12:58:18 |
| vcunat | And I don't see a significant advantage in doing something unusual, but I might be missing something. | 12:59:15 |
| emily | hmm does the going straight into hte next staging count as unusual? | 13:05:20 |
| emily | the only thing I thought of was we could repoint the Python stuff at a copy of the vulnerable git and land git/gitFull updates early | 13:05:43 |
| emily | kind of gross though | 13:05:47 |
| emily | what's the shortest -next we've had recently? feels like they are getting longer and longer | 13:13:19 |
| emily | I guess probably one of the release branch ones :) but even in terms of just builds | 13:13:34 |
| vcunat | They're longer in the period when we keep building two stables. | 13:30:36 |
| emily | ah, I meant a longer "recently" than that, but yes that makes sense | 13:31:02 |
| vcunat | Very often staging-* builds take roughly only a half of Hydra's time, contrary to what people would expect. | 13:31:12 |
| emily | I wonder if having stricter backporting rules for oldstable (e.g. only security updates, nothing else) would help | 13:31:48 |
| emily | it's pointless to backport minor bumps and new features and non-critical bugfixes but maybe they add up to a meaningful proportion of builds? especially if people are just blanket backporting stuff to both stagings or whatever | 13:32:18 |
| vcunat | Not significantly, I believe. | 13:32:26 |
| vcunat | Well, I'd say that a large part is from kernel updates. Though NixOS tests. But it's mostly a gut feeling from lots of observations. | 13:33:08 |
| vcunat | * Well, I'd say that a large part is from kernel updates. Through NixOS tests. But it's mostly a gut feeling from lots of observations. | 13:33:18 |
| emily | I wonder how many NixOS tests could be done with containers without kernels instead. | 13:34:31 |
| emily | e.g. nspawn | 13:34:34 |
| emily | would need auto-allocate-uids so that the derivations can get enough UIDs for unprivileged user namespaces I guess. and actually you'd need to pass through nsresourced, which could get funny. | 13:35:11 |
| vcunat | That's more impurity, though. | 13:35:12 |
| vcunat | * That would be more impurity, though. | 13:35:18 |
| emily | yes. but checkPhase already is impure in the same way, right? | 13:35:33 |
| emily | we would still want tests using full VMs to test stuff that is somehow kernel-relevant, but for random service modules it doesn't feel high-value | 13:35:56 |
| emily | (we could run every build in a VM with a pinned kernel but don't) | 13:36:20 |
| emily | similarly tests don't use the full bootloader flow by default even though that is less end-to-end coverage | 13:36:32 |
| emily | anyway, just an idea. it would unfortunately be annoying to implement because of ^ | 13:36:56 |
