Re: The future of commit access policy for core Firefox

I think "r+ with nits" would be much less of an issue if the
trust/permissions
model was less coarse, both in level of permission and breadth of code it
encompasses. It seems a little bit insane to me that a developer who
primarily
works on area X of the codebase and is given scm_level_3 due to trust in
that
area can then land to any other part of the tree.

Attempts to fix this for parts of mozilla-central have been implemented with
push hooks[1]. Having a generic way to assign this ownership/trust for all
parts
of the codebase (and actually making it enforceable, rather than just
checking
a user providable string in a commit message) would give automation the
information it needs to relax certain requirements in explicitly defined
cases.

For example, it probably makes sense to allow the owner of a particular file
to land there when given an r+ on a previous revision of the change,
especially
if that review came from another owner or peer of that file. If you'd like
to
keep an audit trail, automation could even send out an interdiff of what was
reviewed and what was landed, after the fact.

It seems to me like it's time that an actual machine readable code ownership
system is implemented (Like most large orgs have). Allowing some level of
trust
to keep people productive makes sense to me, but I don't think the current
scm_level system provides enough control to grant reasonable trust we can
enforce with automation.

As Gijs mentioned, you could also allow reviewers to just fix the nits
themselves. Have tools support the reviewer pushing up an alternative fix
(or
editing directly in a review interface) and suggesting it as a change which
the
author could accept and land after viewing the differences.


[1]
https://hg.mozilla.org/hgcustom/version-control-tools/file/tip/hghooks/mozhghooks/prevent_webidl_changes.py