cla_* groups have been retired for a long time. They were previously associated with employer-specific CLAs, which we don't offer anymore.

I would caution against a group for a specific employer, as that will get messy really quickly. Instead, if you have a particular purpose, create a SIG around that purpose and pull Intel and non-Intel folks alike into that SIG.

@aekoroglu What are the things you'd like to organize around specifically? Is it shared package ownership/responsibilities, or something else?

Yes @mattdm, generally what we would like to have is shared package ownership/responsibilities.

For that it sounds like you would want a 'intel-sig' group? basically that would allow you to manage who is in the group and add the group to particular packages (which grants members that priv level) and have a private mailing list where bugs that group is cc'ed on go.

Yes @kevin exactly, but is possible to create such a sig? Because we have no vendor specific sigs in Fedora as I know. OTH this week I created two non-responsive maintainer issue, Intel could be the only vendor who faced with this situation.

We don't have any other sigs like that, but technically it should work fine.

It seems a little off to me for a fedora sig to be based on employment, instead of shared interest, but... it should work I would think.

If no one has objections, we can set it up.

I'm not sure this is a good idea. It doesn't actually fix the non-responsive maintainer issue, we still need those triggering when people disappear. Having a SIG that's based on employment to allow that rotation to happen invisibly is potentially a bad thing, since it prevents us from knowing someone is gone.

I'm not sure I follow... if a user in the group is non responsive, but other people in the group step up and do the work, that should be fine right?

We probibly have a number of existing sigs with folks that are no longer around, we don't have much way of knowing there either. :(

fwiw in the case of meta we did get a meta-sig group created a while ago, but that's only used for copr and we've purposefully avoided using it for package permissions.

I remember discussing this on the list in the past and the consensus was that employee-based groups weren't really appropriate for package permissions, as packagers are individually responsible for what they maintain, not their company. As @ngompa suggested, if you can come up with a functional grouping for the packages you care about so that a real SIG can be formed around them, that's probably a better course of action here.

A real SIG, that is based on interest not employment sounds more interesting to me too, even if the initial membership was based on employment.

Anyway, @aekoroglu after all the feedback, what do you want to do?

Well we have 10~15 packages for now maintained by Intel employees and we're planing to add much more soon. SIG might not be the right environment I agreed but still a solution is needed because those packagers are not just individually responsible for what they maintain.

But as it seems the idea is not welcomed, in this case somehow we should find an internal solution for that.

Keep in mind that groups cannot be the primary maintainers of packages anyway, so this doesn't necessarily solve your problem either.

Yeah, depending on the exact problem you are trying to solve. :)

Groups cannot be main admins, but the do provide commit access to members of the group to those packages. So, you can use a group to adjust for people arriving/departing. You of course still need someone to be main admin...

Also see https://pagure.io/fesco/issue/2966.