| 1 May 2024 |
 Mic92 | In reply to @jacg:matrix.org
Just in case I'm missing something important here, what exactly do you mean by 'rearrange the release notes'? Is there any larger-scale work to be done beyond things like making sure that the individual descriptions make sense and they adhere to a fairly consistent style? Sometimes they can be shortend a bit. We tend to have quite large release notes. There should maybe also a summary of important changes in a section above -> This is also for tech news website that will write about the new NixOS release. | 13:54:45 |
| Mic92 | Also we have a wide range of writing skills in the community, so some editing is required. | 13:55:17 |
|  NixOS Moderation Botchanged room power levels. | 15:07:22 |
| 2 May 2024 |
 @alejandrosame:matrix.org | In reply to @jacg:matrix.org
Just in case I'm missing something important here, what exactly do you mean by 'rearrange the release notes'? Is there any larger-scale work to be done beyond things like making sure that the individual descriptions make sense and they adhere to a fairly consistent style? In the previous release notes, I had as an editorial goal the rearrangement of sections. lennart (this account will be deactivated by 1st of may 2025) and I used a workflow that was not merged (context: https://github.com/NixOS/nixpkgs/pull/270967#issuecomment-2090332676), which turned into me sending a big update that moved pieces of text around, which complicated fixing the last minute release merge conflicts.
So, it's best to try to quickly merge drastic release notes changes ASAP to master. Although, my impression was also that towards the end of of the release cycle, the actual source of truth from the release notes perspective is the frozen branch, which then should be amended to master, not the other way around. At least, until we manage to get more granular control by generating the release notes.
| 12:17:22 |
 Randy Eckenrode | I have a question about breaking changes. Is it breaking if a change does not affect eval or cause rebuilds, but it imposes a new restriction? Darwin dropped curl from the bootstrap, but it is possible for it to sneak back into the bootstrap. I have a change to make it throw, but that would prevent using fetchgit if you happen to be in the Darwin bootstrap. | 14:25:09 |
| Randy Eckenrode | If it is, I can target 24.11 after staging opens back up to breaking changes. | 14:28:31 |
 Weijia | It doesn't sound breaking to me (correct me if I'm wrong). | 14:35:20 |
 raitobezarius | In reply to @reckenrode:matrix.org
I have a question about breaking changes. Is it breaking if a change does not affect eval or cause rebuilds, but it imposes a new restriction? Darwin dropped curl from the bootstrap, but it is possible for it to sneak back into the bootstrap. I have a change to make it throw, but that would prevent using fetchgit if you happen to be in the Darwin bootstrap. can someone depend on that? | 14:36:53 |
| raitobezarius | if so, it's a breaking change | 14:36:59 |
| raitobezarius | if not, it's not | 14:37:00 |
| raitobezarius | if it's a breaking change that's likely to be depended upon 0.5 folks, you can negotiate with RMs to find a compromise | 14:37:16 |
| Randy Eckenrode | Sounds breaking because a package could switch to fetchgit or add curl as a dependency. | 14:38:42 |
| Randy Eckenrode | Which happened with docutils. It’s fixed now, but other packages can do that. | 14:39:43 |
| Randy Eckenrode | I can keep it a best effort exclusion for 24.05 and make it a hard block for 24.11. It’s not critical. More of a QoL improvement for curl updates. | 14:40:56 |
| Randy Eckenrode | * I can keep it a best effort exclusion for 24.05 and make it a hard block for 24.11. It’s not critical. More of a QoL improvement for curl updates, which have to go through staging anyway. | 14:41:16 |
| raitobezarius | Yeah, if it requires active cooperation from the package maintainer, this will be hard | 14:49:08 |
| raitobezarius | There's a compromise which is that during ZHF, people can fix it | 14:49:18 |
| raitobezarius | But this is risky IMHO | 14:49:25 |
| raitobezarius | I don't have all the technical details in front of me, sorry, so I would leave it to the folks on the top of the release process | 14:49:39 |
|  Hayden joined the room. | 20:42:07 |
| Randy Eckenrode | The work to remove curl is done. I’m pretty sure making it throw in the bootstrap can be done without causing any rebuilds (because curl isn’t used, so why would it?). It’s a breaking change semantically though. What was once allowed will be disallowed. But I agree it could be risky since someone may need to put curl back as part of fixing something for ZHF. It can be sorted out, but ZHF is probably not the time to do it. | 22:10:36 |
| Randy Eckenrode | Actually, maybe it should be put in the release notes as a coming change after 24.05 and then done after the release? | 22:16:05 |
| Randy Eckenrode | * Actually, maybe it should be put in the release notes for 24.05 and then done after the release on unstable? | 22:16:23 |
| 3 May 2024 |
| Mic92 | Randy Eckenrode: so from my understanding you mainly try to prevent darwin's bootstrap from using curl? This seems like it's more important for nixpkgs-unstable anyway, so maybe it is not super important that we have that in the NixOS release anyway because people on that branch wouldn't do such changes. | 14:11:48 |
| Randy Eckenrode | In reply to @joerg:thalheim.io
Randy Eckenrode: so from my understanding you mainly try to prevent darwin's bootstrap from using curl? This seems like it's more important for nixpkgs-unstable anyway, so maybe it is not super important that we have that in the NixOS release anyway because people on that branch wouldn't do such changes. Yeah, just preventing it so curl updates don’t require a full Darwin rebuild (and because it’s historically a pain point for Darwin). Sticking with unstable makes sense. | 15:25:00 |
| 4 May 2024 |
|  @theophane:hufschmitt.net left the room. | 15:55:18 |
| 5 May 2024 |
|  andmuz joined the room. | 11:38:46 |
|  westexjeff changed their profile picture. | 18:38:38 |
| 6 May 2024 |
| Weijia | ZHF: https://github.com/NixOS/nixpkgs/issues/309482 | 07:42:02 |
 Vladimír Čunát | The staging-next that's starting now (link) can still contain general "breaking changes", given they were only disallowed a few days ago. But I hope it won't impact ZHF that much. | 07:47:35 |
