Address the cases where submitter is also the maintainer of the code
changed and other areas are being changed. In this case, assign to the
next area maintainers instead of assigning to submitter.
Example: maintainer of component A introduced significant changes to
area A but also makes changes to other areas B and C. Right now
maintainers of B and C are added as reviewers.
This change will assign to the next area after A, i.e. B in cases where the
submitter is also the maintainer of area A.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Noticing many PRs that wait too long in the queue although once of the
maintainers approved with asignees set to other maintainers.
This changes the current behavior of picking the first maintainer in the
list and assigning to them only, instead we assign to all maintainers of
the main area being changed.
Who ends up driving the PR to a mergeable state is then to the
maintainers and they can unassign/assign based on availability.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Previously, one-line changes were tagged as "Trivial".
The description of the "Trivial" label states:
"Changes that can be reviewed by anyone, i.e. doc changes, minor build
system tweaks, etc.".
Just because a change only affects a single line of code, it does not
mean that it is a trivial change. It may have difficult to understand
implications which require approval of the responsible maintainer.
For this reason, change the label to "size: XS" and let humans judge
if a PR is trivial or not.
Signed-off-by: Martin Jäger <martin@libre.solar>
Refactor the skip collaborator logic to add log messages when a
collaborator is skipped because they self removed of not part of the
org.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
The "Submitter is same as Assignee" is comparing strings to <Area> and
always failing the condition, fix it by dropping the ".name".
Tested with ./scripts/set_assignees.py -v -y -P 67526 (now falls back to
the other maintainer as it should).
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
If a collaborator removes themselves from the reviewer list, do not
attempt to re-add them on changes to the PR.
Fixes#67214
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Cleanup of script and change how we assign PR in general:
Make sure that when multiple areas are changed, including platform or
driver changes, we set assignee of the general areas and not the
platform maintainers. For example, if I change 100 SoC files and touch
the kernel file, the assignee is set to the kernel maintainer.
First, we should as much possible try and split such changes and not
have common area changes with platform changes at the same time. Second,
it is important that such changes which affect everyone are reviewed and
approved by the maintainer of the general areas rather than leave them
to the platform maintainer.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add support for setting reviewers as well for module PRs, in addition to
the assignees.
Note that this still only works on repositories with an assignee on
record since it does not seem to be possible to query for PRs that have
no reviewers.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Fix an "if" that should have been an "elif". This is currently causing
the script to fallback into the "do all unassigned PRs of the day" path
when a PR is specified.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Add a -I option to process an issue and, if it's not assigned already,
add assignees based on the labels, matching the ones set in the
MAINTAINERS file areas.
Suggested-by: Henrik Brix Andersen <henrik@brixandersen.dk>
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Add a -m option to set_assignees to have the script find all unassigned
module PRs for areas that have an assignee and set the assignee on those
PRs.
This should help avoiding forgotten PRs on modules. It's implemented as
a search and meant to run periodically, so we don't have to add a
workflow for this on every individual module.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
The set assignee script currently exits if there's too many labels
associated with a PR. Change that to just skip the label assignment, but
continue on to assign a maintainer based on the most relevant area.
Tested with:
./scripts/set_assignees.py -v --dry-run -P 52716
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Disables allowing the python argparse library from automatically
shortening command line arguments, this prevents issues whereby
a new command is added and code that wrongly uses the shortened
command of an existing argument which is the same as the new
command being added will silently change script behaviour.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
When there are more than 15 reviewers, the `set_assignee` script was
adding the reviewers more or less on a random basis because the input
set was arbitrarily ordered (thanks to how Python "set" works), and the
attempt to add any reviewers beyond the count of 15 results in the
previoulsy added reviewer being removed.
This commit updates the `set_assignee` script such that:
1. The collaborator list (input for generating the reviewer list) is
ordered by the area match, such that the collaborators of the most
relevant area come first.
2. The reviewers of the relevant areas are added first, until the total
reviewer count is 15. The script does not attempt to add more than
15 reviewers because that can result in the previously added
reviewers being removed from the list.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
The log refers to Platform taking precedence but the loop handles
Documentation as well. Move it under the proper section, drop "Drivers"
as that is not handle in any special way.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
The script right now assumes that all the areas have a maintainer and
that the second area in particular has one in case of Documentation,
that results in a ValueError when it's not the case. Handle that by
checking the lists before using them.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
If PR already has an assignee, do not add additional assignees to the
PR. Each PR should only have one assignee (in most cases)
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Use MAINTAINERS.yml file to set lables, assignees and reviewers for
specific PRs or all unassigned PRs since a given date.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Anas Nashif