| 21 May 2024 |
 hexa | that sounds unnecessarily expensive | 12:29:08 |
 vcunat | Not much compared to the recent direct S3 access, I expect. | 12:29:47 |
| vcunat | But I expect it would offer too little extra value. | 12:30:08 |
| vcunat | (assuming the 6 ISOs work no worse than 5 in all situations) | 12:30:35 |
| vcunat | * (assuming the v6 ISOs work no worse than v5 in all situations) | 12:30:45 |
| vcunat | 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 |
| vcunat | It's in nixos-unstable. | 22:34:38 |
| vcunat | * It's in nixos-unstable now. | 22:34:43 |
| vcunat | 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 |
| 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 constant merge conflicts, because everyone appended e.g. at the end of the list. 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:32 |
| Weijia | I guess it might work if we replace the comment with something like "please keep the entried alphabetically sorted" for 24.11 | 14:52:57 |
| Weijia | * I guess it might work if we replace the comment with something like "please keep the entries alphabetically sorted" for 24.11 | 14:53:06 |
 Alyssa Ross | Ah, like all-packages.nix? :P | 14:59:30 |
| Mic92 | I like the approach that the nix package manager now uses with separate files. | 15:04:09 |
| Mic92 | * I like the approach that the nix package manager now uses with separate files for the changelog. Would even make more sense for nixpkgs | 15:04:22 |
 adamcstephens | for packages, maybe we could even colocate them with the package itself? | 15:05:16 |
| Mic92 | In reply to @hexa:lossy.network
vcunat: ^ @room Meeting in 55 minutes in https://jitsi.lassul.us/24.05-branch-off | 15:05:46 |
| hexa | In reply to @qyliss:fairydust.space
Ah, like all-packages.nix? :P It probably took me a year to notice that all-packages had multiple categories, that were each individually sorted alphabetically 🫠| 15:07:08 |
