A better solution would be to have in-tree metadata files providing
subscription rules for code review (e.g. a mapping of usernames to a list
of patterns matching files). Module owners would be responsible for
reviewing changes to these rules to ensure that automatic delegation
happens to the correct people.
I still don't believe this would work well in practice. It would work,
but would have frequent problem cases and often require a lot of updating.
at the end of the day tooling needs to ensure that reviewer has the
authority to approve changes.
i don't think the issues you've raised are show stoppers; it's certainly
a system we will iterate on over time.
keep in mind _how_ we work is also something we should be iterating on too.
the current system is extremely coarse - everyone with scm-level-3 can
approve any change tree-wide.
there is a strong desire to make this finer grained.
[snip]
Some modules (i.e. DOM) already to have a hard requirement for peer
review. That should be continued and should be enforced as it is now,
and it sounds like Lando will (does?) support that. If another module
wants to enforce it we can flip a bit in the list of peers and have it
enforced.
the enforcement you're referring to is controlled by a hardcoded list of
peers inside a mercurial hook.
this doesn't scale anywhere close to our needs, and all of the exact
same concerns you raise with regards to in-tree ownership tracking
applies (however it would be worse as it's imposed by a system separate
from the review/landing tooling).
-glob
--
glob — engineering workflow — moz://a
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
