OWNERS, OWNERS_ALIASES: scope to forked project contributors

[lyarwood]

What this PR does

Before this PR:

OWNERS_ALIASES listed all upstream kubevirt/kubevirt contributors across all SIGs, most of whom are not working on this fork. The OWNERS file also referenced an undefined emeritus_approvers alias.

After this PR:

OWNERS and OWNERS_ALIASES are scoped to only the five people actively working on this forked project: vladikr, jean-edouard, xpivarc, lyarwood, and fossedihelm. SIG groups with no remaining members are set to empty arrays so Prow falls back to top-level OWNERS for those areas.

References

Why we need it and why it was done in this way

This fork has a smaller team than upstream kubevirt. Keeping the full upstream OWNERS list means people not working on this project could be assigned reviews or approvals. Scoping to the active contributors ensures correct review routing.

The following tradeoffs were made:

• Several SIGs (Network, Storage, Observability, Scale) now have empty reviewer/approver lists. Reviews for those areas will fall back to the top-level OWNERS (approvers: vladikr, jean-edouard, xpivarc; reviewers: lyarwood, fossedihelm).

The following alternatives were considered:

• Removing the empty SIG groups entirely, but keeping them as empty arrays avoids breaking any sub-directory OWNERS files that reference those aliases.

Special notes for your reviewer

Coverage gaps to be aware of:

• No dedicated owners: Network, Storage, Observability, Scale (fall back to top-level)
• Single person in both roles: SIG Test and SIG Buildsystem (xpivarc only)
• No reviewers: SIG Compute Instance types (lyarwood is sole approver)

Checklist

• Design: A design document was considered and is present (link) or not required
• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Testing: New code requires new unit tests. New features and bug fixes require at least one e2e test
• Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
• Community: Announcement to kubevirt-dev was considered

Release note

NONE

[kubevirt-bot]

There are empty aliases in OWNER_ALIASES, cleanup is advised.

[kubevirt-bot]

There are empty aliases in OWNER_ALIASES, cleanup is advised.

[fossedihelm]

/lgtm

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jean-edouard, lyarwood

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [jean-edouard]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kubevirt-bot]

There are empty aliases in OWNER_ALIASES, cleanup is advised.

[lyarwood]

@jean-edouard I guess this means we should add you and @vladikr as a sig-compute-reviewers in kubevirt/kubevirt?

[jean-edouard]

Not all approvers want to be reviewers, but in this case yeah I should be a sig-compute-reviewers (and you a sig-compute-instancetype-reviewers? :) )

[lyarwood]

kubevirt/kubevirt#16958

[lyarwood]

/hold cancel

[fossedihelm]

/lgtm