I do not like having to do .maintainers but I still want to have attrsets so we do not have to repeat #36119

Makes sense, I wouldn't have to have a pkgs.pantheon.maintainers or pkgs.gnome3.maintainers anymore (that doesn't make sense at the pkgs level anyway).
I was thinking of adding myself to glib and gtk3 today but this idea returned to me and thought "I'd rather take the time to have this". Guess our idea was floating around again 😄

Yeah, colord-gtk is package without meta.maintainers but I did not want to add myself directly.

So just an idea dump, I think I might've talked about having something where this could map to NixOS Teams so when there's official "working groups" ofborg could request their review. Autolabeing issues for the groups would be nice also, and it would help with people figuring out who's the best person/s to reach on most things. But that's probably an idea that would needs the organizational effort of an RFC.

I like the idea of having the maintainer-groups being centralized to a single location. Hard to know which packages have maintainers like mesa, gtk, etc

This is much healthier for nixpkgs core/important packages and will make keeping things up to date so much easier. I love it!

Maybe renaming it to lib.teams.freedesktop.members would be little bit nicer to type.

Eventually, we would like to be able to just add a group directly to the meta.maintainers list but that would require changes to OfBorg and Hydra. (Though it should not be a difficult change, just merging and deduplicatiom.) We can leave that for future PRs when this proves useful.

One disadvantage of the current implementation is that it is not possible to find out all packages maintained by a group. That would be useful for maintainers/scripts/update.nix. Maybe we should go directly to phase two as described above.

@jtojnar So the idea here is that teams are special groups of maintainers that have shared responsibility, ownership, and accountability. They've like maintainers but they operate more collectively, and there's a usually an ongoing internal discourse and larger infrastructures to be accountable for.

I don't think this makes teams a different meta attribute, just a different type of maintainer.
And maintainers list should should be taught groups as you said.

I do think this could be useful right away, it's just when ofborg requests reviews it'll be as individuals.
But people can still read the source description of teams. Phase two as described is a good idea.

Though it is a fundamental thing, should we land more gracefully? It's more difficult to organize changes like this that have many pieces. So if something is committed first it'll be easier down the line.

Here is an example how the first-class teams could be handled by ofborg: NixOS/ofborg#421

Though it is a fundamental thing, should we land more gracefully? It's more difficult to organize changes like this that have many pieces. So if something is committed first it'll be easier down the line.

On the other hand, not having first-class teams at first would mean having to modify every instance of legacy use. And it could possibly hinder adoption because of people waiting for a better implementation.

@ofborg eval

I'm just a little concerned about the following scenario:

meta = with lib; {
  ...
  maintainers = with maintainers; with teams; [ jonringer grahamc ] ++ freedesktop.members;
  ...

hard to know where the attr's are coming from, I guess it could be changed to:

meta = with lib; {
  ...
  maintainers = with maintainers; [ jonringer grahamc ] ++ teams.freedesktop.members;
  ...

similar to the PR, and that's fairly acceptable.

Knowing what attr's are being introduce by a with clause has been a consistent user-pain for nix, even outside of this PR. So I won't hold it against it.