| 27 Mar 2022 |
 hexa | * since it will soon be time to ping all package set maintainers, how could I formally join the python-band without subscribing to the madness that is pkgs/development/python-modules via CODEOWNERS? Subscribing there makes GitHub notifications entirely unusable. | 16:15:08 |
 Janne Heß | In reply to @hexa:lossy.network
since it will soon be time to ping all package set maintainers, how could I formally join the python-band without subscribing to the madness that is pkgs/development/python-modules via CODEOWNERS? Subscribing there makes GitHub notifications entirely unusable. I thought about that as well and my idea was to take the list of Subsystem: @maintainer and put it into the release wiki. If every RM just uses this list, people who want to join/leave can just PR against the release wiki. Would that work for you? | 17:29:46 |
| hexa | better, put it into the nixpkgs repo so people can manage it themselves | 17:30:16 |
| hexa | * better yet, put it into the nixpkgs repo so people can manage it themselves | 17:30:29 |
| Janne Heß | great, I didn't think of that :O | 17:30:41 |
| Janne Heß | maintainers/subsystem-maintainers.txt maybe? | 17:30:57 |
| hexa | in gentoo joining a team is managed by existing team members and advertised on a wiki page | 17:31:11 |
| Janne Heß | I'll PR it and wait for a discussion to arise 🤷 | 17:32:47 |
 Vladimír Čunát | We have stuff like meta.maintainers = teams.gnome.members; | 17:35:13 |
| Vladimír Čunát | I mean... why txt? | 17:35:51 |
| Janne Heß | Do you think all people would be happy with being part of the team-list? | 17:36:37 |
| hexa | oh yeah, reusing maintainer teams is a good idea | 17:38:54 |
| hexa | I think this is a structured solution and a good middle ground | 17:39:25 |
| Janne Heß | I agree with that for the language subsystems but what about these?
Nix/nix-cli ecosystem: @edolstra @grahamc @nbp @Profpatsch
Mobile: @samueldr
Nixos Modules / internals : @Infinisil @Ericson2314 @alyssais @roberth
Nixos tests: @tfc
Marketing: @garbas @tomberek
Docs: @ryantm @Mic92
Release: @tomberek @Mic92
| 17:39:37 |
| Janne Heß | (sorry if I pinged anyone…) | 17:39:53 |
 John Ericson | lol you did | 17:49:59 |
| Janne Heß | :( Won't happen again, sorry | 17:50:11 |
| John Ericson | don't worry about it :) | 17:56:17 |
 Sandro 🐧 | They could also be thrown into the maintainer teams. Than we can use them in derivation and so, too. | 22:44:31 |
| Janne Heß | I will try tomorrow if I find the time | 22:44:58 |
| 28 Mar 2022 |
|  vlinkz joined the room. | 00:27:42 |
| Janne Heß | Second attempt with the teams list and a script: https://github.com/NixOS/nixpkgs/pull/165978 | 12:27:08 |
| Janne Heß | In reply to @hexa:lossy.network
this feels like something that should be done once every release and a release manager wiki entry could be helpful to make sure it happens What timespan should that be? Everything older than 1 year prior to the expected release date? (so June 2021 for 22.05) | 18:20:14 |
| hexa | I think it has two stages: 1) convert aliases to throws 2) remove throws | 18:20:57 |
| Janne Heß | ah right… I didn't look at the mentioned PR | 18:21:56 |
| Janne Heß | * ah right… I didn't look at the mentioned PR too much | 18:21:58 |
| hexa | a throw is the first user-facing action unless you've disabled aliases | 18:22:00 |
| Janne Heß | So since this is the first release with that logic, we don't remove any aliases this time? | 18:22:18 |
| Janne Heß | I have this for the wiki now:
- Remove old aliases that have been `throw`s for at least one release. There is
a script in the nixpkgs tree to do that:
`maintainers/scripts/remove-old-aliases.py --file
./pkgs/top-level/aliases.nix --year 2019 --month 6`
The conversion to `throw`s is usually done in one big Pull Request so you can
remove all aliases from the date prior to this Pull Request. [Example of the
2022 throw conversion](https://github.com/NixOS/nixpkgs/pull/161146).
| 18:25:53 |
|  LilleCarl joined the room. | 20:29:57 |
