Lack of rules to avoid intentional abuse of power in someone else's subproject

[avolkov-1221]

Introduction

This issue was raised in discussions and during the sequence of actions for PR #75740. The current Zephyr policy and documentation do not clearly explain the roles and permissions of "collaborators" and "maintainers" outside of their subprojects.

Problem description

The "collaborator" user from one project has added the 3rd person from his company as a "maintainer" to the unrelated project and took the maintainer's role for this project without any public announcement or permission.

Proposed change

Roles and permissions have to be described in more detail. In particular, what exactly users with write permissions are allowed to do outside of there subprojects. Also rules for revoking permissions from violators should be added.

Detailed RFC

Proposed change (Detailed)

Clarification will help reduce potential conflicts of interest and avoid the nasty "Embrace, Extend and Extinguish" practice, where someone with write permission is hired by a company and allows that company to shortcut or, worse, to bypass the commit acceptance process without testing, discussion, or taking the community's interests into account.

Dependencies

Concerns and Unresolved Questions

Alternatives

[jfischer-no]

@avolkov-1221 Is it about #75740?
The bot assigned it incorrectly, probably due to clock control changes. But I guess it is not just that, right?

[avolkov-1221]

Yes,

@avolkov-1221 Is it about #75740? The bot assigned it incorrectly, probably due to clock control changes. But I guess it is not just that, right?

Yes, it's. The problem is not in the bot, but the overstepped authority by Yiannis Damigos ("collaborator"): he has made a person with no experience with Zephyr as a "maintainer", and then assigned him to a competing PR as an "Assignees".

[avolkov-1221]

@avolkov-1221 Is it about #75740? The bot assigned it incorrectly, probably due to clock control changes. But I guess it is not just that, right?

PS @jfischer-no my last reply is here #75740 (comment)

[jfischer-no]

#75498 updated Renesas RA Platforms and hal_renesas maintainers. I would not blame Yiannis Damigos. The PR was approved and merged as usual. The trust probably comes from the fact that this vendor joined the project. Whether a vendor then inherits all the boards, and a vendor representative becomes a maintainer, is an interesting question. By the way, it is not that dramatic; the person with no experience is not the only maintainer in the area.

[avolkov-1221]

#75498 updated Renesas RA Platforms and hal_renesas maintainers. I would not blame Yiannis Damigos. The PR was approved and merged as usual. The trust probably comes from the fact that this vendor joined the project. Whether a vendor then inherits all the boards, and a vendor representative becomes a maintainer, is an interesting question. By the way, it is not that dramatic; the person with no experience is not the only maintainer in the area.

I agree that Yannis probably acted with the best of intentions, and I don't really wish to blame him either, but the result doesn't look so good in any case. We have a real 'conflict of interest' with Renesas (they wish to push their FSP's dependency at any cost), which I personally resisted. As a result, my PR is frozen, regardless of the quality of my code, but due to personal decision. And we don’t have a clear arbitration on how to resolve this situation. IMO "assignee" have to be neutral 3rd party person, not from competitive subproject.

I think that the situation with 2 competing PRs at the same time will most likely not happen again, however the situation with overstepped authority is likely to happen repeatedly. Therefore, I propose to clarify the hierarchy and boundaries of authority, in order to avoid such conflicts in the future.
For example, either the project maintainer or the top-level one, as an exception, can add a new maintainer/collaborators and reassign "assignee", but not some person from unrelated subproject.

As far as I remember, this is exactly how it's done in Linux: maintainers outside of their projects are not so different from regular developers and do not have increased permissions. I propose to reuse it, only replacing almighty Linus with WG :).

[ydamigos]

@avolkov-1221 Is it about #75740? The bot assigned it incorrectly, probably due to clock control changes. But I guess it is not just that, right?

PS @jfischer-no my last reply is here #75740 (comment)

@ydamigos Are you kidding me? It was you, who pushed him through as a maintainer, violating Zephyr's rules:

He became a maintainer without a single verified commit, just based on trust in you.

PR #75498 was approved by the maintainer of RA platform before it was merged. Moreover, I asked specifically about it #75498 (comment).

And the first PR from this team contained serious violations of many of Zephyr's code guide requirements, which shows that they lack experience. He shouldn't have become a "maintainer", nor should they have become "collaborators" without proper preparation.

Are we talking about PR #72150. Please provide a list of the violations so we can address them. Afaik, Zephyr's code guide requirements don't apply to vendor HAL, do they?
Kheim, Thao and Duy are very familiar with RA family and FSP. I believe they are perfect candidates for maintainer and collaborators role. They may lack experience with Zephyr code base but we should support them and help them to gain it. I believe exposing them to Zephyr's community is the perfect and proper preparation for them to grow as developers (I am talking from personal experience). As I see it, it's a win win situation for Zephyr project / community and them.

Then, as a "collaborator", not "maintainer", in an external project, you overstepped your authority and assigned him responsible for a competing PR.

I just added one of the maintainers, should I add or change it to @soburi instead?

Yannis, this looks like some dirty political game on your part to pushing vendor lock at any cost, rather than proper code collaboration within the community.

There was already PR #71174 which added support for RA2 family which using FSP not originating from Renesas which was approved and merged. I don't believe that Renesas team is doing anything "behind the scenes".

[fabiobaltieri]

@avolkov-1221 it's a bit tricky to understand the issue if you don't reference to the controversial PR/issues, at least we have inspector @jfischer-no to the rescue, but seriously, just link the PR/issues that you think need to be reevaluated an then one could check them out and draw some conclusion, I really don't see the point in being vague or trying to hide the fact, people are just going to either waste time searching for the data or disengage. Anyway, I see two problems here:

We have a real 'conflict of interest' with Renesas (they wish to push their FSP's dependency at any cost), which I personally resisted. As a result, my PR is frozen, regardless of the quality of my code, but due to personal decision. And we don’t have a clear arbitration on how to resolve this situation. IMO "assignee" have to be neutral 3rd party person, not from competitive subproject.

This sounds like an architecture issue, should probably go through the Arch WG, ideally with a presentation of the pro/con of each approach (I'm assuing FSP is a Renesas hal and the discussion is whether to use it or not?). This is a technical problem and should be threated as such, the project should evaluate and adopt the technically superior solution.

Yes, it's. The problem is not in the bot, but the overstepped authority by Yiannis Damigos ("collaborator"): he has made a person with no experience with Zephyr as a "maintainer", and then assigned him to a competing PR as an "Assignees".

This is more of a process problem, it may make sense to have stricter criteria for the various roles, maybe have some automation to further restrict who can be set as "assignee" to a pull request since that field has lot of implication (this came out at release meeting yesterday, again with no context, but it makes more sense now).

[nashif]

The "collaborator" user from one project has added the 3rd person from his company as a "maintainer" to the unrelated project and took the maintainer's role for this project without any public announcement or permission.

if you are referring to #75498:

• This is the documented process.
• change was submitted and was reviewed and approved, this is the same as "public announcement" (submitting a PR) and permission (Review + Approval)

from his company as a "maintainer" to the unrelated project

Anyone can propose collaborators to other areas of the project, there is no limitation on this. This will still have to be reviewed and approved.

Unless I am missing something else, I do not see any violation or abuse of power here.

[avolkov-1221]

@fabiobaltieri

@avolkov-1221 it's a bit tricky to understand the issue if you don't reference to the controversial PR/issues, at least we have inspector @jfischer-no to the rescue, but seriously, just link the PR/issues that you think need to be reevaluated an then one could check them out and draw some conclusion, I really don't see the point in being vague or trying to hide the fact, people are just going to either waste time searching for the data or disengage.

I've tried to elevate and concentrate here only on the hierarchy/permissions/borders of authority problem, without involving the personalities. Sorry if not so successful. I've added the PR id to the description.

Anyway, I see two problems here:

We have a real 'conflict of interest' with Renesas (they wish to push their FSP's dependency at any cost), which I personally resisted. As a result, my PR is frozen, regardless of the quality of my code, but due to personal decision. And we don’t have a clear arbitration on how to resolve this situation. IMO "assignee" have to be neutral 3rd party person, not from competitive subproject.

This sounds like an architecture issue, should probably go through the Arch WG, ideally with a presentation of the pro/con of each approach (I'm assuing FSP is a Renesas hal and the discussion is whether to use it or not?). This is a technical problem and should be threated as such, the project should evaluate and adopt the technically superior solution.

Agree, the "FSP" (and more generally, manufacturers HALs in the modules) is other problem, and IMHO now is a real headache. Actually almost unrelated to the topic. Would you like me to create a separate ticket for this?

Yes, it's. The problem is not in the bot, but the overstepped authority by Yiannis Damigos ("collaborator"): he has made a person with no experience with Zephyr as a "maintainer", and then assigned him to a competing PR as an "Assignees".

This is more of a process problem, it may make sense to have stricter criteria for the various roles, maybe have some automation to further restrict who can be set as "assignee" to a pull request since that field has lot of implication (this came out at release meeting yesterday, again with no context, but it makes more sense now).

Exactly. However, I suppose that for now, simply updating the documentation should be enough: reassigning the "asignee" already requires elevated status, some experience, and involvement in Zephyr's development. For a random external person do it not so easy.

[fabiobaltieri]

I've tried to elevate and concentrate here only on the hierarchy/permissions/borders of authority problem, without involving the personalities. Sorry if not so successful. I've added the PR id to the description.

Not a problem, I acknowledge and admire the effort, but I think that the context is important and leaving it out for the sake of not pointing finger is just confusing.