| 4 Oct 2025 |
 leona | it might be, otherwise I don't know how helpful a tracking issue would be. We already have the label 2.status: wait for branch-off for PRs and issues that are blocked. I feel like a tracking issue is only really helpful when multiple people (and not just the maintainers of the respective module or package) can work on the issues. But also just my idea
Personally, I more like the idea for reducing the time where breaking changes are restricted by branching off earlier, but this would possibly require more energy and especially Hydra capacity, that we currently don't have. This idea was already mentioned last release cycle by multiple people, but IMO currently not actionable
| 07:45:33 |
 dish [Fox/It/She] | i mean multiple people could work on the issues or pull requests, but most things are just marked with comments and you need to search through the code to find stuff, since most likely it gets forgotten | 15:34:19 |
| 6 Oct 2025 |
|  tallyho-dulcet joined the room. | 09:16:41 |
|  felix joined the room. | 12:52:18 |
| 7 Oct 2025 |
 Vladimír Čunát | Ideally we'd cut the breaking changes to release-critical packages now already, not moved to the weekend. | 15:11:53 |
| Vladimír Čunát | Or leave them to more careful approval. | 15:12:36 |
| Vladimír Čunát | But I think most of the relevant people know staging-next + release scheduling and the need to get breaking changes early. | 15:13:10 |
| Vladimír Čunát | * But I think most of the relevant people know staging-next + release scheduling and the need to get breaking changes early anyway. | 15:13:14 |
| leona | For me this would be fine. As far as I understood it, most people just wanted to move breaking changes to non release critical packages further back. But I leave that also up to jopejoe1 | 15:14:10 |
|  alunduil changed their profile picture. | 23:11:54 |
| 8 Oct 2025 |
|  @pfpoitras:matrix.org left the room. | 04:51:31 |
 jopejoe1 (4094@epvpn) | No strong opinion on that, but from what i understood there where also some changes to release critical packages people wanted to get in. | 20:02:39 |
|  Uraraka ~ Ochaco joined the room. | 20:55:35 |
| Uraraka ~ Ochaco changed their display name from Peri to dwd. | 20:55:57 |
| 9 Oct 2025 |
| Uraraka ~ Ochaco | Ahoy hoy, a bunch of packages just broke in unstable due to not having updated to cmake 3.5, is that going to be reflected in 25.11 or is it going to wait until 26.05? | 16:21:55 |
| Vladimír Čunát | Current master is 25.11. | 16:23:57 |
| Vladimír Čunát | You can see the fork-off in the schedule | 16:24:16 |
| Uraraka ~ Ochaco | ah ok | 16:24:21 |
| Vladimír Čunát | * You can see the branch-off in the schedule | 16:24:39 |
| Vladimír Čunát | in a couple weeks: https://github.com/NixOS/nixpkgs/issues/443568 | 16:24:45 |
 kuflierl | That sounds like a significant issue, maybe keep the old version as default? | 16:25:02 |
| Vladimír Čunát | * in a several weeks: https://github.com/NixOS/nixpkgs/issues/443568 | 16:25:12 |
| Vladimír Čunát | I'd say that ship has sailed. There was hope to reduce this a lot during ZHF. | 16:25:39 |
| Vladimír Čunát | * in several weeks: https://github.com/NixOS/nixpkgs/issues/443568 | 16:25:53 |
| jopejoe1 (4094@epvpn) | We have the ZHF phase of the release to work on fixing those | 16:25:59 |
| leona | Also, we need to update at some point and reverting this and delaying even further won’t help anyone | 16:26:08 |
| Vladimír Čunát | Well, if I knew how it will go, I would've preferred to delay it by several months. | 16:26:50 |
| Vladimír Čunát | As I don't see much benefits from having the newer cmake as default. | 16:27:03 |
| Vladimír Čunát | But at this point I'd say it's way too late to revert. | 16:27:14 |
| Vladimír Čunát | (and it doesn't seem that bad; lots of work has gone into fixes already) | 16:27:32 |
