| 21 Sep 2022 |
 Winter (she/her) | agreed | 13:05:25 |
 Mic92 | Something like, these are the new cool feature why you want to upgrade or switch to nixos too. | 13:05:54 |
 Janne Heß | In reply to @joerg:thalheim.io
*honest We could condense them into a list. Something like Major updates: postgresql 13 → 14, samba: 4.15 → 4.16, coreutils: 8.4 → 9.2, … Then anyone who is interested can skim the list | 13:06:08 |
| Winter (she/her) | Yup. Deciding what those are might be A Process, but we can cross that bridge when we get to it. | 13:06:21 |
| Winter (she/her) | (I'm not even sure how we'd figure this out, for changes that aren't currently in the WIP notes.) | 13:06:42 |
 Vladimír Čunát | I'd prefer to drop any except where there's a significant incompatibility. | 13:07:23 |
| Vladimír Čunát | (and except very significant packages like nix) | 13:07:41 |
| Winter (she/her) | (insignificant) updates, you mean? | 13:07:46 |
| Winter (she/her) | ah | 13:07:47 |
| Vladimír Čunát | It's default that we update packages to latest versions. | 13:08:01 |
| Winter (she/her) | Basically things that don't really matter unless you look for it, and nothing that warrants further explanation? | 13:08:16 |
| Winter (she/her) | * Basically things that don't really matter unless you want to look for it, and nothing that warrants further explanation? | 13:08:23 |
| Mic92 | We could just point people to the package search, if they want to find out what versions changed too. | 13:09:55 |
| Mic92 | So only package upgrades where manual intervention is required would be listed. | 13:10:26 |
| Winter (she/her) | So that's for the packages portion -- what about NixOS? Do we want to list new modules, are there relatively a small amount usually that it would make sense to list them all) | 13:11:10 |
| Winter (she/her) | * So that's for the packages portion -- what about NixOS? Do we want to list new modules, are there relatively a small amount usually that it would make sense to list them all? | 13:11:13 |
| Winter (she/her) | I think that might be a good thing to still do, but maybe we can list a few "major" modules and give them a more detailed overview of what they can achieve that would be annoying before? | 13:17:26 |
| Winter (she/her) | Not really sure of an example though. | 13:17:39 |
| Mic92 | Last release I started listing all modules. | 13:17:52 |
| Mic92 | But to be honest I think there were too many | 13:18:01 |
| Mic92 | I just didn't had to much time to filter | 13:18:12 |
| Winter (she/her) | So we can go with listing/showing off "major" ones I guess, depending on how that looks? | 13:18:35 |
| Mic92 | Yeah, and then maybe switch to a big paragraph just naming them. | 13:19:01 |
| Mic92 | So the bigger ones get an explanantion while the smaller ones could be linked to | 13:19:27 |
| Winter (she/her) | In reply to @joerg:thalheim.io
Yeah, and then maybe switch to a big paragraph just naming them. Naming the ones we don't call out you mean) | 13:19:56 |
 Linux Hackerman | Ideally the modules would all have docs that can be linked to :> | 13:19:56 |
| Winter (she/her) | *? | 13:20:00 |
| Winter (she/her) | In reply to @linus:schreibt.jetzt
Ideally the modules would all have docs that can be linked to :> options.html hides /s | 13:20:18 |
| Mic92 | I was thinking of just doing something like: [modulea](alink), [moduleb](blink), [module](clink) | 13:21:09 |
| Winter (she/her) | Yes, but are we also keeping the "major" modules explanation thing, or are you saying doing that in place of it? | 13:22:00 |
