 | Release Management | 345 Members |
| 25.11 "Xantusia" | https://nixos.github.io/release-wiki/Home.html | 93 Servers |
| Release Management | 345 Members |
| 25.11 "Xantusia" | https://nixos.github.io/release-wiki/Home.html | 93 Servers |
| Sender | Message | Time |
|---|---|---|
| 21 Apr 2024 | ||
 Arian | thanks! | 13:25:38 |
| Arian | I guess I'll ahve to update that document regarding the AWS AMIs | 13:25:47 |
 @stablejoy:matrix.org | Im reading the release wiki and following here. What can a beginner do to help? Its exciting but not sure how could I help | 13:44:37 |
 raitobezarius | There's two tasks a beginner can do: (a) You can look at pick up the garbage: https://github.com/NixOS/nixpkgs/projects/18?query=is%3Aopen+sort%3Aupdated-desc -- only if you have expertise with the aforementioned software, otherwise you may just create needless noise for people (b) Wait for the Zero Hydra Failure process where the goal is to minimize all the failures | 13:49:54 |
| @stablejoy:matrix.org | I understand, thanks | 13:51:01 |
 jonringer | For the upcoming meeting for RMs and REs, the main points of the meeting I would like to address:
| 17:15:25 |
 Weijia | Link to the meeting: https://jitsi.lassul.us/nixos-2405 | 17:57:33 |
| jonringer |
| 18:35:10 |
| jonringer | Things I would like to see in the release notes:
| 18:42:07 |
 @jacg:matrix.org | Any guidelines on how granular we want the commits and PRs to be? | 21:37:24 |
| @jacg:matrix.org | Should we change package names to inline code blocks (backticks) and match the package's pkgs attribute name? For example, should things like 'YouTrack is bumped to 2023.3. become 'youtrack is bumped to 2023.3.' ? | 21:42:08 |
| @jacg:matrix.org | * Should we change package names to inline code blocks (backticks) and match the package's pkgs attribute name? For example, should things like 'YouTrack is bumped to 2023.3.' become youtrack is bumped to 2023.3.' ? | 21:42:29 |
| @jacg:matrix.org | * Should we change package names to inline code blocks (backticks) and match the package's pkgs attribute name? For example, should things like "YouTrack is bumped to 2023.3." become "youtrack is bumped to 2023.3." ? | 21:42:54 |
| @jacg:matrix.org | Concerning 'Ensure that the affected programs/services appear at the beginning of the release note" are we happy with "The mpich package expression now requires ..." or should this become something like "mpich: the package expression now requires ..." ? | 21:46:26 |
| @jacg:matrix.org | * Concerning "Ensure that the affected programs/services appear at the beginning of the release note" are we happy with "The mpich package expression now requires ..." or should this become something like "mpich: the package expression now requires ..." ? | 21:50:11 |
 teto | jonringer: might I enquire why the quote of my pending PR description ? Is the descriptio not good enough :'( ? | 22:27:40 |
| 22 Apr 2024 | ||
| @jacg:matrix.org | teto: In yesterday's meeting the release editors were asked to ensure that the name of the affected package or service appear at the beginning of each note, for easy visual parsing/filtering of items. Yours was simply given as an example of a note where the package name first appears further in the text of the note. | 07:02:39 |
| jonringer | Yea, that was all | 14:39:27 |
| jonringer | You PR was just the first PR with the Appreciate what you do for lua and vim :) | 17:30:54 |
| jonringer | When referencing packages in release notes, example: https://github.com/NixOS/nixpkgs/pull/305965/files#r1575114124. I feel like we should:
Not sure how people feel about my suggestion here. This fixates more on the nixos option rather than project itself. | 17:37:52 |
| jonringer | I guess related to what I said above, is that trying to normalize related changes become odd when switching between referencing packages by their title vs their nixpkgs attr path:
Should we trying to keep as nixpkgs as possible, unless it detracts from comprehension? | 17:43:04 |
| jonringer | * I guess related to what I said above; is that trying to normalize related changes becomes odd when switching between referencing packages by their title vs their nixpkgs attr path:
Should we trying to keep as nixpkgs as possible, unless it detracts from comprehension? | 17:43:45 |
| jonringer | * I guess related to what I said above; is that trying to normalize related changes becomes odd when switching between referencing packages by their title vs their nixpkgs attr path:
Should we try to keep diction "as nixpkgs" as possible? unless it detracts from comprehension? | 17:45:22 |
| @jacg:matrix.org | I'm tempted to go for attribute names over brands, favouring comprehension over aesthetics. | 20:29:11 |
| 23 Apr 2024 | ||
| @jacg:matrix.org | Some notes give version numbers as code blocks, some as normal text. Should we make these consistent? If so, which way? I lean towards code blocks, to make them stand out. | 08:44:31 |
 @theophane:hufschmitt.net joined the room. | 12:14:39 | |
| Weijia | I'd prefer version numbers to be normal text, like 24.05 instead of 24.05. | 13:48:02 |
| jonringer | Do you have an example? | 15:06:50 |
| jonringer | In reply to @jonringer:matrix.orgnevermind, took a look at https://github.com/NixOS/nixpkgs/pull/306235 | 15:22:07 |
| jonringer | I might side with Weijia on this one, the codeblocks are used extensively for packages and nixos options (things that are supplied by nixpkgs and NixOS). I don't think using codeblocks for versions would increase readability. | 15:24:19 |