• Hydra may be affected because the maintainers field is now not a list of strings but a list of sets
• I can undo the indentation of the list of maintainers for now to prevent merge conflicts
• fix meta-checking
• maintainers/scripts/hydra-eval-failures.py

• fix meta-checking

... but I'm personally not yet sure that this is a good approach. For example, we're growing per-package resources needed for evaluation all the time, and growing the number of packages as well. Evaluation is something we do really often, even if it's typically partial.

Evaluation of meta is fixed.

... but I'm personally not yet sure that this is a good approach. For example, we're growing per-package resources needed for evaluation all the time, and growing the number of packages as well. Evaluation is something we do really often, even if it's typically partial.

This may indeed require additional resources. I would have to test whether it is anything significant. I do think we should have this information available. An alternative would be to simply list the different fields instead of computing them as is done now.

Yes, I'd consider just committing the textually transformed code, probably depending on the real measurements.

I hope there are no other tools depending on the "type" of *.meta.maintainers ...

IIRC Hydra looks at the maintainer list and will need a patch. I think I remember @edolstra saying to do it and he'd take care of the patching.

• https://github.com/NixOS/hydra/blob/62c6cca937859ce02e74ed78c2d6fe420d7d8387/src/lib/Hydra/Helper/CatalystUtils.pm#L293
• Structured maintainers #31739 (comment)

This seems overly complicated to me. Why do we need that all that funky _structuredMaintainers and ... business? I would just change lib/maintainers.nix to return a attrset of attrsets.

2017-11-16 13:51:55     gchristensen    I propose we make a branch where we just do it, create a jobset to see just how it breaks hydra and then see what we do
2017-11-16 13:51:56     niksnut fixing hydra will take 5 minutes
2017-11-16 13:51:57     MoreTea cool.
2017-11-16 13:52:26     gchristensen    or maybe niksnut knows how it breaks hydra and knows it won't be so terrible for people who use it
2017-11-16 13:52:41     niksnut I think it will just ignore it
2017-11-16 13:52:46     MoreTea clever pointed me to where it's actually used.
2017-11-16 13:52:47     gchristensen    perfect!
2017-11-16 13:53:02     MoreTea So I'll create two PR's then, one for the update of lib/maintainers.nix, and one for hydra ;)
2017-11-16 13:53:04     MoreTea thanks!
2017-11-16 13:54:18     niksnut MoreTea: I can fix hydra, it's probably a lot easier for me
2017-11-16 13:54:29     niksnut unless you want to do some C++ hacking

Thanks @grahamc.

So, the goal is indeed to have a set of sets, instead of what is in this PR. Regardless, I think this PR can be used to test the required changes to Hydra. Therefore, I propose

1. use this PR (merge it or keep this branch) so
2. we can fix Hydra
3. and then rewrite this PR or Structured maintainers #31739 to have the set of sets.

@GrahamcOfBorg eval

Please also include @0x4A6F handle in this pr

Honestly, I think the best thing to do is just break hydra and make the change all at once. Then we can get it in and call it done. Eelco didn't seem concerned about this approach, as far as I could tell.

Does that mean we have to backport the schema change to 17.09? (I'm not sure how much Hydra breaks.)

I don't know, but I doubt it. My impression is the patch for Hydra would be pretty simple.

Would it rustle your jimmies if I reformatted the whole thing to be a uniform, extensible object?

{ foo = {
  name = "Profpatsch";
  email = "my@email.com";
  github = "Profpatsch";
  wiki = "Profpatsch";
}; }

This way there is no special-casing necessary and other fields can be added once the need arises (and tooling doesn’t have to make sense of every single field).

@Profpatsch eventually every maintainer should indeed be described by such a set, see the struct. I did not want to make this change until Hydra supports it.

@FRidh Graham said we should just go forward with changing to an attrset, Eelco will follow with hydra; #36119 used this PR as basis and corrected all wrong github handles.