7 Oct 2024 |
Randy Eckenrode | The Darwin rework stuff is targeting the next staging-next cycle. If the cycle starts late, how does that interact with the freeze? | 04:30:33 |
| emily joined the room. | 04:33:52 |
| Austin Horstman joined the room. | 04:46:19 |
| aviallon ⚡️ joined the room. | 10:34:15 |
| aviallon ⚡️ | 10:34:19 |
Tristan Ross | In reply to @reckenrode:matrix.org The Darwin rework stuff is targeting the next staging-next cycle. If the cycle starts late, how does that interact with the freeze? For one, the PR should be merged before the 11th. On the 30th, we have a staging-next -> master merge. | 15:47:59 |
Randy Eckenrode | I’m hoping it’s merged well before the 11th. | 15:49:05 |
emily | if the staging-next cycle starts after the 11th, does it really matter when the PR is merged? | 15:49:05 |
emily | (I don't know how likely that is though) | 15:49:11 |
emily | there's already breaking changes in the next staging and the cycle will happen when it happens anyway | 15:49:23 |
Randy Eckenrode | The issue is this cycle is taking a bit longer and cause the next one go later. | 15:49:31 |
vcunat | 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 |
vcunat | * 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 |
vcunat | Yes, the staging* merges don't go exactly according to the plan. | 15:52:19 |
vcunat | 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 |