|
The gerrit owners plugin allows much more tight grained control over
what files in a repository require which approvals. This would allow
OpenBMC to use the primary openbmc/openbmc repository for most recipe,
distro, and conf file submissions, relying on the owners plugin to gate
code checked into meta layers for which they were not allowed.
At this time, this file only has the effect of automatically adding
owners to gerrit reviews. It requires a separate config change to the
rules.pl and project.config to start obeying these for the submissions.
My intention with this commit is to first populate the OWNERS files into
the subtreed meta-* directories. After that the autobump scripts will
push the new changes into the main tree, and we will end up with
openbmc/openbmc that now posesses OWNERS files for all the meta layers.
Once that is in place, we can then enable the owners plugin on
openbmc/openbmc. If it has any unintended impact, we can always roll it
back, and go back to the owners plugin being non-enforcing.
This commit includes the root OWNERS commit.
Open questions that I suspect we can answer later and as we have more
experience with this.
1. Should we set inherited to true in all cases, some cases, or never?
Inherited means that directories above the one specified inherit the
privileges above it, ie, the sub OWNER can merge anything in the tree
below it. I suspect this will need to be a case by case basis.
2. Is there a way to specify a special OWNERS file for meta layers that
we don't own (meta-oe and others) that provides messages back to the
submitter automatically that they should submit their changes directly
to upstream? For the moment, the permissions just roll up to the root,
and require the root maintainer to comment directly, but it seems likely
we could automate this.
Tested:
I've built a gerrit test project as a test that enables these changes,
and submitted
https://gerrit.openbmc-project.xyz/c/openbmc/owners-plugin-test/+/39365
and
https://gerrit.openbmc-project.xyz/c/openbmc/owners-plugin-test/+/39366
As examples of both positive (should be allowed to merge) and negative
(shouldn't be allowed to merge) tests. In both cases, they act as
expected, where even if the negative commit is +2 code review and +1
verified, it will not be allowed to merge until the owner +2s it.
signed-off-by: Ed Tanous <ed@tanous.net>
Change-Id: I6f33acfd12382f8eb7cb1e9ae56046c40de18635
|
