| 7 Oct 2024 |
 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 |
| Randy Eckenrode | * (I expect to find some breakage on staging-next, but my testing went so smoothly compared to the LLVM upgrade that I’m not expecting much.) | 15:58:15 |
| 8 Oct 2024 |
| emily | https://github.com/NixOS/nixpkgs/issues/339153 seems wrong. it implies that breaking changes are never forbidden on master | 07:03:25 |
| emily | compared to https://github.com/NixOS/nixpkgs/issues/303285 | 07:03:32 |
| emily | also, I didn't realize that the Oct 11 deadline was only to compilers and systemd. | 07:04:33 |
| emily | that means that Randy Eckenrode technically has until Oct 25 anyway, since the only GCC change isn't breaking… | 07:05:04 |
| Randy Eckenrode | The Darwin stuff seems in the spirit of a compiler. Anyway, I hope it doesn’t take to the 25th because I’m unlike to be available after the 18th. | 11:59:35 |
 Tristan Ross | In reply to @emilazy:matrix.org
https://github.com/NixOS/nixpkgs/issues/339153 seems wrong. it implies that breaking changes are never forbidden on master How does it seem wrong? I copied from the release wiki. | 13:52:21 |
 Lily Foster | In reply to @emilazy:matrix.org
https://github.com/NixOS/nixpkgs/issues/339153 seems wrong. it implies that breaking changes are never forbidden on master pretty sure the intent is to restrict at the same time as staging is, as was done in 24.05 https://github.com/NixOS/nixpkgs/issues/303285. though admittedly release wiki nor rfc85 ever included that | 14:11:28 |
| emily | it implies that breaking changes are only forbidden on staging branches | 14:11:53 |
| emily | which the 24.05 issue differed on | 14:12:09 |
| emily | In reply to @lily:lily.flowers
pretty sure the intent is to restrict at the same time as staging is, as was done in 24.05 https://github.com/NixOS/nixpkgs/issues/303285. though admittedly release wiki nor rfc85 ever included that so it's a chronic problem, ok 🫠 | 14:12:32 |
| Randy Eckenrode | Given the Darwin stuff can’t go to master, what the policy is for master doesn’t pertinent. My only concern is getting the Darwin stuff into 24.11. | 14:14:35 |
