ci: set_assignee: Only consider significant maintainers

[Thalley]

Summary

If a PR is created by the maintainer of an area, then the maintainer is usually the assignee.
However, the current set_assignees.py script will always attempt to replace the author with another maintainer if there is one: https://github.com/zephyrproject-rtos/zephyr/blob/main/scripts/set_assignees.py#L134-L150

The problem is that if an author creates a PR with 1000 lines of code changes, where the author is the maintainer for the areas of 999 of those lines, and there is another maintainer for the last 1 line of change, then the other maintainer will be assigned. This is for example fairly often the case with a PR that implements a new API function for their own area, where there is a single line in the release notes, and the maintainers for the Release Notes area are assigned instead.

Describe the solution you'd like

The set_assignees.py should take the number of line changes into account, and only overwrite the author as the assignee, if there exists a maintainer of another area, where the number of files changed for the other area is significant, e.g. at least 10% of the PR.

The assignee should be the maintainer of area with the most changes, or if maintainer == author, then the maintainer oft he area of with second-most changes, but at least 10% of the lines of code changes (or any other relative value).

Alternatives

No response

Additional Context

No response

[Thalley]

(just a disclaimer, I did look at the current code a bit to see if I could add this somewhat trivially, but it seems that we count changes in # of files, rather than # of lines - For the above to work we should use # of lines: If a PR add 999 lines in one file and 1 line in the release notes, then it's still 50% of the files).

[nashif]

this a known problem (at least to me) and i have a patch somewhere to address it, but never got to it.

In most cases where meta area maintainers are assigned, you are welcome to re-assign yourself. This is primarily done to deal with mixed PRs changing too many things and getting assigned to the wrong areas, for example I change the a board and the kernel and the PR get assigned tgo the board maintainer and kernel changes slip in without any review etc.

Will rework my patch and submit asap.