| 29 Apr 2024 |
|  Frank Geusch joined the room. | 17:17:51 |
| Frank Geusch changed their display name from Frank Geusch to Master Fudge. | 17:28:05 |
| 30 Apr 2024 |
|  ondt joined the room. | 22:06:01 |
| 1 May 2024 |
 @jacg:matrix.org | In reply to @infinisil:matrix.org
So my suggestion to resolve that: Rearrange the release notes as early as possible, such that they just need minor polish towards the release date 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? | 08:04:48 |
 infinisil | jacg Let me pingalejandrosame, he did that last time | 08:06:32 |
| infinisil | 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? https://github.com/NixOS/nixpkgs/pull/270967 | 08:08:07 |
| @jacg:matrix.org | A number of links in the release notes MD source have a $ where I would expect a #, for example [services.davis]($opt-services-davis.enable). Does this have some meaning that has escaped me, or are these the consequence of people missing the # key and hitting the adjacent-on-many-keyboards $ instead? | 12:48:55 |
| infinisil | In reply to @jacg:matrix.org
A number of links in the release notes MD source have a $ where I would expect a #, for example [services.davis]($opt-services-davis.enable). Does this have some meaning that has escaped me, or are these the consequence of people missing the # key and hitting the adjacent-on-many-keyboards $ instead? No I think you got it, there's no $... syntax | 13:21:56 |
 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 |
