tree 9dd0aed20c47c7426b6ac93d58d70b4bb3802ab5
parent 3d006a10b05565a2927167ed10cb3157bfb03be3
author Edwin Kempin <ekempin@google.com> 1608555968 +0100
committer Edwin Kempin <ekempin@google.com> 1610028277 +0100

Allow to specify a seed that should be used to shuffle code owners

When code owners of a path are listed, code owners that have the same
score are returned in a random order. This is done to fairly distribute
the review work among the code owners.

However the random order is a problem for the grouping of files with the
same code owners that is done in the Gerrit frontend. The frontend
queries 5 code owners for each file and then groups files that have the
exact same code owners. If files have more than 5 code owners with the
same score it is random which of them are returned to the frontend. This
means for files that have the same code owners, the frontend may get a
different sets of random code owners, and hence the grouping does not
work. As a result of this the frontend shows more groups to the user and
users need to pick more code owners as reviewers. If there are many
files and code owners, this can easily lead to situations where the user
is presented many more files groups than would be necessary.

To fix this we now allow the caller of the list code owners REST
endpoints to provide a seed that should be used to shuffle the code
owners that have the same score. By generating a seed and using this
same seed for getting code owners suggestions for all files in a change
a stable sort order of code owners with the same score can be achieved
for all the files. This means the same random users will be suggested
for all files that have the same code owners, and hence the grouping in
the frontend will work much better.

This change only adds the support for setting a seed in the requests in
the backend. A follow-up change still needs to adapt the frontend to
generate a seed and set it on the requests. This should only be done
after this backend change has been rolled out.

Using the same seed for different requests only makes the sort order
stable if the same seed and the same limit is used. Using the same limit
is important because using the same seed for sorting only results in the
same order if the input list has exactly the same elements. If the input
list as more or fewer elements due to a different limit, the order will
be different. This limitation is fine for us, since the frontend will
execute all requests with the same limit.

The sort order is not guaranteed to be stable if new accounts are
created in between the requests, or if the account visibility is
changed. However we expect this to happen rarely, and if it happens it's
not a big issue as it only leads to less good grouping of code owners in
the code owner suggestion.

Signed-off-by: Edwin Kempin <ekempin@google.com>
Change-Id: Id59a4d92e6101a9bf860e931d919a5cdf24045ef