Request for Maintainer rights to Pawel Stankiewicz, Oniro sysadmin/release engineer

Summary

@pastanki is the Oniro sysadmin/release engineer. In order to play his role at Oniro, he needs maintainer roles, assigned only to project leaders. He requires such roles across the different Oniro project. So fa, oniro-core.

What is the current bug behaviour?

Today the Maintainer role (gitlab role) is linked to the Project lead role (Eclipse F. project governance role). Project leads are usually software development leads.

Now that we are using Gitlab for delivery and not just for product development, it makes sense to provide also Maintainer roles to the lead sysadmin/release engineer. From a gitlab/technical perspective, this is the person who is in charge of setting up and maintaining the pipelines as well as several other services and configurations.

But this person might not necessarily is a leading role from the governance point of view.

It seems to me there are two ways to approach this topic:

1. We assign @pastanki the project lead role, so he has permissions on gitlab assigned to Maintainers
2. @pastanki is assigned Maintainer roles without being project lead, this is, we unlink the governance role from the gitlab role under this new scenario.

@pastanki as project lead

• Pros: consistency
• Cons:
  • @pastanki is not playing a lead position from the governance perspective. Such role has associated and responsibilities he currently does not have or eve want.
  • Given the responsibility and demands associated to this position, a backup would be most likely needed.

@pastanki as gitlab maintainer at oniro-core without becoming a project lead

• Pros: compatible with the current role @pastanki is playing.
• Cons: exception for projects that uses Gitlab as delivery tool implies overhead and risks from the Gitlab management perspective.

According to my understanding, the EMO and the IT teams need to discuss this request and communicate which way to go.

What is the expected correct behaviour?

@pastanki one way or the other, gets Maintainer role assigned so he can better support the Oniro technical team.

@malowe am I assuming correctly that the GitLab sync script would reset elevated permissions (maintainer) for non-project leads back to developer permissions? (so it would require some tinkering with the GitLab sync script to be able to define such an exception)

That is correct. The logic for this is under the addUserToGroup function, and it checks user access level if already added and fixes it if its not the one that's expected.

assigned to @wbeaton

@wbeaton we need your input on this one: do you have any concerns about assigning the project lead role only for the sake of handing out the right permissions?

changed title from Request for Mintainer rights to Pawel Stankiewicz, Oniro sysadmin/release engineer to Request for Maintainer rights to Pawel Stankiewicz, Oniro sysadmin/release engineer

changed the description

+1 for project lead on a temp basis.

In the end, if the current Project Leads are OK with making @pastanki Project Lead, then I'm good.

/cc @idlethread /cc @agherzan

We need your input / +1

@droy I support temporary Maintainer access to @pastanki to allow him to complete setting up CI for Oniro.

@toscalix Thanks for the summary. Is there any other issue that is currently discussing the role of project lead vs. non-lead and the permissions assigned to them? I'd like to participate in that conversation.

@fgurr Can you provide a pointer to this permission reset script so we might study it to better understand how EF maps policy to Gitlab permissions?

Is there any other issue that is currently discussing the role of project lead vs. non-lead and the permissions assigned to them? I'd like to participate in that conversation.

Not that I am aware of.

@droy I also vote to unblock this by elevating @pastanki 's role to Maintainer. It sounds like this is the only way forward at this point given the dependencies on the tools EF is using to maintain these roles.

I've added @pastanki as Project Lead, which will elevate to maintainer in a short while.

Thanks @droy

@toscalix Thanks for the summary. Is there any other issue that is currently discussing the role of project lead vs. non-lead and the permissions assigned to them? I'd like to participate in that conversation.

Here is a related discussion: Allow delegation of Maintainer role to non-project leads #64

@fgurr Can you provide a pointer to this permission reset script so we might study it to better understand how EF maps policy to Gitlab permissions?

You can find the permission mapping here: https://gitlab.eclipse.org/eclipsefdn/it/webdev/eclipsefdn-github-sync#gitlab-permissions-mapping (yes, the repo name is ambiguous)

Given the current correlation we apply between governance roles and gitlab roles, the solution to this problem has been to make Pawel commiter/project lead. I consider this a hack.

In open source projects today there are "service roles" that do not participate on the governance of "the code" (development activities) but requires access to and rights to many different areas and services. IT services people is just one example, but there are others like security, compliance (not just related with licenses) testing...

I hope that soon we can contemplate this reality somehow without having to make them participate of the governance of the project in areas they are not. A higher level of segmentation is required in order for our structure to match reality.

I proceed to close this ticket. I will collect use cases and limitations of our current model targetting eclipsecon 2022

closed

@toscalix two things:

1.We were leaving this open to track the removal of @pastanki from Project Lead role. Should we now remove the hack , or should we leave @pastanki in that role indefinitely

2. "I hope that soon we can contemplate this reality somehow" If you'd like to propose a change to the process, may I recommend filing an issue and stating the requirements? Otherwise, we have nothing tracking what needs to be done.

Replying to point 1., we need to leave @pastanki in that role until we have agreed to the new requirements and landed them. Anything else will lead to disruption to the Oniro project.

• I support @idlethread suggestion

"I hope that soon we can contemplate this reality somehow" If you'd like to propose a change to the process, may I recommend filing an issue and stating the requirements? Otherwise, we have nothing tracking what needs to be done.

I am thinking on something in the line of the use case we have created for the private repos and channels (communicated through a ticket). Instead of precluding how we want things, given that the users (Oniro devs) do not have the full picture on how the services are running and the requirements attached to these, we expose the needs and the current limitations, so we at EF can work internally to find solutions. Some of the limitations Oniro devs are facing are related to core EF values/designs, some hit processes at EF but some are purely implementation policies. My hope is that, facilitating the structuring of developers needs based on that logic can bring us to some solutions that reduces some of the pain earlier. We'll see how the private repos discussion end up and, if it works well, we will follow the logic/process from the user PoV.

I mentioned EclipseCon 2022 because I think it is a good time to sit down together and show in person the limitations that, hopefully, will be documented in advance.

If you'd like to propose a change to the process, may I recommend filing an issue and stating the requirements? Otherwise, we have nothing tracking what needs to be done.

"given that the users (Oniro devs) do not have the full picture on how the services are running"

How so? What information is needed? Please limit the ambiguity.

If you'd like to propose a change to the process, may I recommend filing an issue and stating the requirements? Otherwise, we have nothing tracking what needs to be done.

This is good proposal. As soon as we put together our thought around this, we will open such ticket, yes.

"given that the users (Oniro devs) do not have the full picture on how the services are running"

I was not providing any criticism to the level of transparency we have at EF. I was simply pointing out that, in general, Oniro developers understand the needs of the infrastructure and services for them. They can also have a sense of requirements we face based on prior experience, but are not experts on them. This is why, I think that we need to discuss a little deeper our proposal so it as compatible as possible with current processes.