| 7 Oct 2024 |
 Vladimír Čunát | There's a period when no breaking changes are allowed. | 15:49:35 |
 emily | I assumed the cutoff was more about not piling more breaking changes into the next cycle | 15:49:36 |
| Vladimír Čunát | * There's a period when no breaking changes are allowed to be merged. | 15:49:44 |
| emily | (but I assume the schedule did not anticipate the weird timing of this current cycle) | 15:50:03 |
 Randy Eckenrode | In reply to @vcunat:matrix.org
There's a period when no breaking changes are allowed to be merged. I’m trying to get ahead of that, but the targeted cycle that wasn’t past the freeze may go late. | 15:50:24 |
| Randy Eckenrode | Does that mean merged into staging or staging-next into master? That’s my point of confusion. | 15:50:57 |
| emily | (surely "On the 30th, we have a staging-next -> master merge." is just projected, anyway? you can't say for certain when a staging cycle will be ready to merge into master) | 15:51:47 |
| Vladimír Čunát | Yes, the staging* merges don't go exactly according to the plan. | 15:52:19 |
| Vladimír Čunát | Or rarely, at least. | 15:54:09 |
| emily | it seems to me that the actual invariant the freeze is meant to express is "no breaking changes after the next staging-next cycle"? | 15:54:41 |
| emily | e.g., if we're not going to run builds of stuff currently going into staging until the 13th and there's already, on the 7th, breaking changes in there, i'm not sure how merging a breaking change on the 12th affects things | 15:55:11 |
| Randy Eckenrode | If staging currently has breaking changes, then it seems like getting the Darwin ones in before the 11th should be fine. If staging-next goes however long, that’s a separate issue. | 15:55:35 |
| Randy Eckenrode | The Darwin changes are … weird. They’re both very breaking and actually not very breaking. If you care about low-level SDK layout, they break you, and you have to fix your code. There’s no other way to end the cycle of SDK mixing. If you just consume framework packages, you probably don’t notice. | 15:56:26 |
| emily | yeah I mean it's not like we can just back out breaking changes that are currently queued | 15:56:27 |
| Randy Eckenrode | Compared to the LLVM upgrade last year, there’s maybe a quarter of packages needing fixed (and some of those are things I’m proactively updating that don’t strictly need it, but seeing how Qt got cleaned up is a good example for Linux maintainers of what the change can do for them). | 15:57:05 |
| emily | hopefully we can just get it merged in the next couple days, anyway. | 15:57:08 |
| Randy Eckenrode | Yeah. That will make render this conversation moot. | 15:57:25 |
| Randy Eckenrode | * Yeah. That will render this conversation moot. | 15:57:31 |
| Randy Eckenrode | (I expect to find some breaking on staging-next, but my testing went so smoothly compared to the LLVM upgrade that I’m not expecting much.) | 15:57:55 |
