commit | 33534c4490dcde8dd352e1f1f799f4bcd52ab478 | [log] [tgz] |
---|---|---|
author | Edwin Kempin <ekempin@google.com> | Thu Feb 18 12:32:50 2021 +0100 |
committer | Edwin Kempin <ekempin@google.com> | Tue Feb 23 14:28:03 2021 +0100 |
tree | 5165ff126a7c28208db6fdc55cdd42d47fd92a99 | |
parent | e9545e14f54695fe50b92a7cedc82bc7515dd955 [diff] |
Return current reviewers first in code owner suggestion The frontend only suggests the best 5 code owners for a file. In the suggestion dialog the frontend shows checkmarks for those files for which one of the suggested code owners has been added or selected as reviewer. If the change already has a reviewer that is a code owner of a file, but this reviewer doesn't appear in suggested 5 code owners, the frontend wrongly shows the file as not covered yet (no checkmark). To fix this we are now returning code owners that are reviewers first when suggesting code owners. If the current reviewers are returned first, they appear in the suggested code owners and hence the checkmarking logic in the frontend will just work. To return code owners that are reviewers first, we add a IS_REVIEWER score next to the existing DISTANCE score. The IS_REVIEWER score is only applied if code owners are listed for a change (since otherwise there are no reviewers). The scoring for the IS_REVIEWER score can be 0.0 (code owner is not a reviewer) and 1.0 (code owner is a reviewer). To ensure that the IS_REVIEWER score takes precedence over the DISTANCE score it has a higher weight. The IS_REVIEWER score has a weight of 2, while the DISTANCE score has a weight of 1. This means for code owners that are reviewers the total score is >= 2.0 (2 * 1.0 + 1 * distance scoring, 0.0 <= distance scoring <= 1.0) while for code owners that are no reviewers the total score is <= 1.0 (2 * 0.0 + 1 * distance scoring, 0.0 <= distance scoring <= 1.0). In order for the sorting to work, we cannot abort the lookup of code owners once we found the best 5 code owners by distance score (or whatever limit is provided), but we must always iterate over all relevant OWNERS files. We already need to do this in most cases to find out if the file is owned by all users, so doing it always now shouldn't make a big difference. Having multiple scores with different weights was planned from the very beginning, just so far we didn't have a need to implement weights as there was only a single score. Bug: Issue 14089 Change-Id: Id2d9f0ebe08be7b613033bf03946190e8d0d849f Signed-off-by: Edwin Kempin <ekempin@google.com>
This plugin provides support for defining code owners for files in a repository.
If the code-owners plugin is enabled, changes can only be submitted if all touched files are covered by approvals from code owners.
Also see resources/Documentation/about.md
IMPORTANT: Before installing/enabling the plugin follow the instructions from the setup guide, see resources/Documentation/setup-guide.md