SIGs and Ownership - Next Steps

[Fabian Deutsch]

Hey,

Throughout last year there were a couple of efforts to look at how to introduce SIGs.

Lee, Alay, and myself did push from different ends.
Now, the good thing is that we have learned. In this iteration we take a more pragmatic approach.

Right now there are 3 phases proposed:
1. Assign existing approvers to SIGs
2. Set SIG ownership on specific paths
3. Follow up with defining the missions and responsibilities of the SIGs

This email is covering phase 1 and 2.

The main goal remains to establish and define special interest groups (SIGs), in order to
- To move the point of contact of an area from a person to a group of people
- Make it easier to find points of contact for an area
- Divide bug scrubbing
- Make it easier to grow new contributors by focusing on one area

Due to the lack of approvers the goal is to find the minimal viable set of SIGs that we need to cover 80% of the codebase.

In this round the proposal is to groom the following SIGs:
- sig-node
- sig-cluster
- sig-network
- sig-storage
- sig-testing
- sig-buildsystem
- sig-release

Most of these SIGs were more or less used in the past, thus there is no new SIG being introduced.

In this round the ask is to define what these SIGs are looking after, thus defining areas in our codease which are owned by each of those SIGs.

The ask to existing approvers is:
1. Add yourself as an approver to the top-level OWNERS_ALIAS file if you see this as an area of your expertise
2. Propose PRs introducing OWNERS files in paths that we can easily associate with one of the SIGs above.

A _minimal_ example can be found in the following PR:
https://github.com/kubevirt/kubevirt/pull/11046/files

Let me just note for transparency reasons that there were some offline discussions in order to understand how a pragmatic approach can look.

Let me also add that this whole topic is wide, nuanced, and decorated with many opinions.
For the best of the project we do have to look at how we put the burden not on individuals but on groups instead, and how we as a project ensure that there is “daily” coverage for every piece of code.

The interested reader can look at how Kubernetes was actually having SIGs almost from day 1.

Looking forward to a vivid and friendly discussion - and (approvers!) PRs to start defining ownership.

Greetings, tipping my maintainer hat,
- fabian

[Luboslav Pivarc]

Hi Fabian,

On Thu, Feb 8, 2024 at 4:29 PM Fabian Deutsch <fdeu...@redhat.com> wrote:

Hey,

Throughout last year there were a couple of efforts to look at how to introduce SIGs.

Lee, Alay, and myself did push from different ends.
Now, the good thing is that we have learned. In this iteration we take a more pragmatic approach.

Right now there are 3 phases proposed:
1. Assign existing approvers to SIGs
2. Set SIG ownership on specific paths
3. Follow up with defining the missions and responsibilities of the SIGs

This email is covering phase 1 and 2.

The main goal remains to establish and define special interest groups (SIGs), in order to
- To move the point of contact of an area from a person to a group of people
- Make it easier to find points of contact for an area
- Divide bug scrubbing
- Make it easier to grow new contributors by focusing on one area

Due to the lack of approvers the goal is to find the minimal viable set of SIGs that we need to cover 80% of the codebase.

In this round the proposal is to groom the following SIGs:
- sig-node
- sig-cluster
- sig-network
- sig-storage
- sig-testing
- sig-buildsystem
- sig-release

Could you spare a few words and tell us what these sigs will cover? I am especially interested in the new ones, sig-node, sig-cluster. The others were used in the past or are self-explanatory enough.

 

Most of these SIGs were more or less used in the past, thus there is no new SIG being introduced.

In this round the ask is to define what these SIGs are looking after, thus defining areas in our codease which are owned by each of those SIGs.

The ask to existing approvers is:
1. Add yourself as an approver to the top-level OWNERS_ALIAS file if you see this as an area of your expertise
2. Propose PRs introducing OWNERS files in paths that we can easily associate with one of the SIGs above.

A _minimal_ example can be found in the following PR:
https://github.com/kubevirt/kubevirt/pull/11046/files

Let me just note for transparency reasons that there were some offline discussions in order to understand how a pragmatic approach can look.

Let me also add that this whole topic is wide, nuanced, and decorated with many opinions.
For the best of the project we do have to look at how we put the burden not on individuals but on groups instead, and how we as a project ensure that there is “daily” coverage for every piece of code.

The interested reader can look at how Kubernetes was actually having SIGs almost from day 1.

Looking forward to a vivid and friendly discussion - and (approvers!) PRs to start defining ownership.

Greetings, tipping my maintainer hat,
- fabian

--
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/CA%2BPVUaRPqdpWannQLWsT_AQmX%2B1DSDW9chPzOnPadjY8t_HfSA%40mail.gmail.com.

[Fabian Deutsch]

Lubo!

Absolutely - And I had hoped that these two new ones would be sefl explanatory as well. but here we go: sig-compute felt huge.

Yes, compute is huge, but by trying to separate this into a cluster and into a node part the idea is to also give attention to the relevant details.

sig-node - Everything which happens on the node. SELinux, CRI, seccomp, hotplug, … handler, launcher namely.

sig-cluster - Everything !sig-node but sig-compute: Broadly spoken: virt-api, virt-controller.

And there are for sure things that overalp. Thus do not consider this binary (initially), but an intent to start defining these areas better, in order to - imagine - new comers to learn them better.

Does this help?

[Luboslav Pivarc]

Yes, thank you.

I would counter this by, "yes, the sig-compute is large but who better can divide it and distribute approvers?" I think each sig should be able to have working groups that would be taking care of more specific areas of the sig. So here I would just go without the sig-node and sig-cluster and let us evolve in the next iteration.

At least this is my opinion/preference.

-Lubo

[Fabian Deutsch]

Thanks.

I think this is a good and pragmatic idea. Let me propose changes!

[Fabian Deutsch]

Lubo,

I prepared a patch. But it feels unpractical to me.

By introducing wg-node and wg-cluster within sig-compute we add a) another layer and b) need to find owners for these areas as well as sig-compute.

I'd like to stick to sig-node and sig-cluster for now mainly for pragmatic reasons.

Please note that even Kube only has sigs on the approvers level (also WGs within sigs to groom certain topics).

Note II: Kube actually has sig-scheduling and not sig-cluster.