| 21 May 2024 |
 Vladimír Čunát |
nixos/release-combined: ship Plasma 6 ISOs instead of Plasma 5
| 12:26:17 |
| Vladimír Čunát | The channel script change does not ship both at once. | 12:26:54 |
 hexa | ok, but this only affects the graphical installer | 12:27:00 |
| Vladimír Čunát | And the channel blocker is also switched, not added. | 12:27:06 |
| hexa | where you can pick either 5 or 6 | 12:27:11 |
| Vladimír Čunát | Yes, at least the PRs that I've seen. | 12:27:20 |
| Vladimír Čunát | It's true that most users won't touch the installer. | 12:27:41 |
| Vladimír Čunát | We could be shipping both. | 12:28:23 |
| Vladimír Čunát | (it would increase costs, though) | 12:29:05 |
| hexa | that sounds unnecessarily expensive | 12:29:08 |
| Vladimír Čunát | Not much compared to the recent direct S3 access, I expect. | 12:29:47 |
| Vladimír Čunát | But I expect it would offer too little extra value. | 12:30:08 |
| Vladimír Čunát | (assuming the 6 ISOs work no worse than 5 in all situations) | 12:30:35 |
| Vladimír Čunát | * (assuming the v6 ISOs work no worse than v5 in all situations) | 12:30:45 |
| Vladimír Čunát | TL;DR: machines are working, we should have it in nixos-unstable within several hours. | 12:34:19 |
 Mic92 | In reply to @hexa:lossy.network
where you can pick either 5 or 6 The update was quiet smooth in my experience. KDE 6 should be good to go. | 14:44:39 |
| Vladimír Čunát | It's in nixos-unstable. | 22:34:38 |
| Vladimír Čunát | * It's in nixos-unstable now. | 22:34:43 |
| Vladimír Čunát | And staging-next got merged, so it should get there very soon as well, I hope. | 22:34:57 |
| hexa | strictly speaking https://github.com/NixOS/nixpkgs/pull/313501 is a breaking change | 22:48:41 |
| hexa | but every maintainer of an affected package has been notified months in advance https://github.com/NixOS/nixpkgs/issues/262907 | 22:48:54 |
| hexa | and fyi https://github.com/NixOS/nixos-homepage/pull/1436 | 22:57:42 |
| 22 May 2024 |
|  @bumperboat:matrix.org joined the room. | 08:30:57 |
 @jacg:matrix.org | Weijia: I see that you have sorted the entries in the release notes. I refrained from doing this because of the comment "<!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. -->
" which, to be honest, I didn't really understand. Should this comment be removed, or is there some merit to it? | 13:04:57 |
 Lily Foster | In reply to @jacg:matrix.org
Weijia: I see that you have sorted the entries in the release notes. I refrained from doing this because of the comment "<!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. -->
" which, to be honest, I didn't really understand. Should this comment be removed, or is there some merit to it? as far as i understand, the comment mostly applies before release process (where breaking changes are restricted and there should be minimal to no new release notes) | 13:07:59 |
| Lily Foster | they're supposed to be sorted (and i guess that comment removed?) during release editing iirc | 13:08:38 |
| Lily Foster | (but, uhhhhh, don't listen to me, read the release wiki. i'm no RM) | 13:08:54 |
 Weijia | In reply to @jonringer:matrix.org
Things I would like to see in the release notes:
- Re-introduction of the "highlights section"
- makes it easy for tech blogs and others to see major inclusions of a release
- Ensure that the affected programs/services appear at the beginning of the the release note
- See above, as an example of a note which can be restructured to have the affected packages ordered in a manner which is easier to parse
In a previous meeting, we've like the affected packages to be ordered | 13:16:34 |
| Weijia | Also, the new services section was ordered in 22.11 and 23.05, not sure why it wasn't in 23.11 | 13:17:12 |
| hexa | In reply to @jacg:matrix.org
Weijia: I see that you have sorted the entries in the release notes. I refrained from doing this because of the comment "<!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. -->
" which, to be honest, I didn't really understand. Should this comment be removed, or is there some merit to it? When hundreds of people contribute to the release notes during the 6 months leading up to the release, then its's best to insert at a random location, as to avoid conflicts. This rule does not apply during release note editing, where existing entries should be sorted/grouped logically, so they're easier to digest. | 14:47:05 |
