| 11 Oct 2025 |
 Yureka (she/her) | given hardening flags also have performance penalties | 11:05:37 |
| Yureka (she/her) | that's what pkgsExtraHardening is for | 11:05:48 |
 K900 | I think what we want is probably
if [compiler explicitly declares supported] then [that] else [some set of sane defaults] - [compiler explicitly declares unsupported] | 11:07:08 |
| 12 Oct 2025 |
|  Anton (he/him) changed their display name from Anton to Anton (he/him). | 13:17:58 |
 emily | can we eat ~10k Ruby rebuilds on -next to fix extension modules with LLVM 21? | 14:21:25 |
| emily | could be conditioned on Darwin only for now | 14:21:30 |
 Vladimír Čunát | Sounds OK to me. | 14:46:55 |
| emily | re the whole doing periodic merges via PR thing | 15:55:00 |
| emily | what if we just used the merge queue to ensure that nothing goes into master or staging-next that won't cleanly merge into the branches after it? | 15:55:17 |
| emily | and switched things around so that, if you would cause a merge conflict on a later branch, you instead merge it into the later branch | 15:55:34 |
| K900 | That is going to completely stall some PRs | 15:55:39 |
| emily | and then "backport" it to the earlier ones | 15:55:40 |
| K900 | I think | 15:55:43 |
| emily | stall howso? | 15:55:51 |
| K900 | Oh god that's going to be so painful | 15:55:53 |
| emily | why? | 15:55:58 |
| K900 | Because nothing will backport cleanly and then we have to check backports and oof | 15:56:12 |
| emily | it means the conflicts can be resolved per-PR | 15:56:03 |
| emily | rather than all at once | 15:56:08 |
| emily | I don't understand | 15:56:22 |
| emily | that's exactly the case of periodic merges failing | 15:56:26 |
| emily | it would be far more auditable and granular than those | 15:56:35 |
| K900 | I'd much rather resolve the conflicts all at once than have random people make three different PRs and compare them against each other | 15:56:58 |
| emily | this would eliminate the conflicts | 15:57:17 |
| emily | there would never be any | 15:57:21 |
| emily | like, exactly when someone would have to manually resolve/check the conflict on staging, the merge would say "this conflicts with staging – target staging instead", and if you need the PR to land in master sooner than that, you would then open a cherry-pick from staging back to master, resolving the conflict | 15:57:57 |
| emily | which a committer could still do – but a contributor could also do, just like with backports to release branches | 15:58:08 |
| emily | it ensures that every change is always targeting the "latest state" whenever there would otherwise be conflicts | 15:58:23 |
| emily | and we never have "master does X, staging does Y, they are incompatible, we find out 6 hours later" | 15:58:31 |
 Wolfgang Walther | This doesn't solve the case of "A is merged into master, in the 6 hour window where A has not made its way to staging, B is merged into staging; A and B conflict". | 15:59:44 |
