tree 5165ff126a7c28208db6fdc55cdd42d47fd92a99
parent e9545e14f54695fe50b92a7cedc82bc7515dd955
author Edwin Kempin <ekempin@google.com> 1613647970 +0100
committer Edwin Kempin <ekempin@google.com> 1614086883 +0100

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>