validate single email per github handle in sigs.yaml

[BenTheElder]

We should be able to validate that we don't wind up with multiple different emails somehow for contributors with entries for multiple SIGs/WGs

follow-up to #8138

[BenTheElder]

uhhhh
/committee steering
/sig contributor-experience

[BenTheElder]

... this is a bit messy to add. We have a validation phase but the output is buried and the make verify scripting is wired only to show a generated diff rather than validation errors.

Really it would be better if we didn't have to duplicate people definitions and refactored them out to be defined once and referred to by github handle within each of the references in groups, but that's a breaking change and I'm hesitant about what may break.

You could imagine using the github handle as a unique key (since github already enforces that) to refer to a single shared map of people by name / employer / email / ...

[palnabarun]

make test can easily add another small script which could validate this restriction. And then the Make target can be added as a presubmit.

On the restriction itself, I am very okay with it. It's a must needed thing.

[BenTheElder]

make test can easily add another small script which could validate this restriction. And then the Make target can be added as a presubmit.

That's a good idea.

I think we should also consider refactoring out the config to avoid duplicating people definitions by design, but I don't know if we have any requirements on the stability of the format.

That would eliminate the need for the test, the need for manual fixups, and the need to manually enter repeated information altogether ...

[jberkus]

... why do I feel like we're constantly re-inventing relational databases?

[palnabarun]

I think we should also consider refactoring out the config to avoid duplicating people definitions by design, but I don't know if we have any requirements on the stability of the format.

Let's take it as a separate concern. We might be over-engineering a flat structure to a relational DB. There are not many people with multiple roles around the community. The number most likely is a handful.

[palnabarun]

... why do I feel like we're constantly re-inventing relational databases?

Haven't YAMLs become databases? 😆 just kidding.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten