Re: The future of commit access policy for core Firefox

Steven MacLeod <[email protected]> Fri, 10 Mar 2017 12:08:25 -0500
Newsgroups gmane.comp.mozilla.devel.seamonkey
Message-ID <CAOsM0xPUag-19W+0mvG-ys=h2ypV3zgsp5ZA3rxjubpSosuYMQ@mail.gmail.com>
On Fri, Mar 10, 2017 at 11:58 AM, L. David Baron <[email protected]> wrote:

> On Friday 2017-03-10 11:33 -0500, Steven MacLeod wrote:
> > 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.
>
> There's a big tradeoff here, which is that we don't want to
> discourage refactoring or cleanup changes that touch large parts of
> the codebase.  Such changes are important for the long-term health
> of the codebase.  To allow them, we've generally allowed the owners
> of an API to review straightforward changes to users of that API
> across all parts of the tree, because getting review from every
> module touched is a significant amount of work and delay, and
> strongly discourages making such refactoring / cleanup changes.
>

In the model I'm proposing, I think there could still be a place for a very
small
number of very trusted developers who could approve changes repository wide.
Vast refactoring could rely on sign-off from one of these developers. I
assume
the number of changes actually requiring such sign-off would be low enough
that it wouldn't overburden this small group? Even if their review was just
a
rubber-stamp indicating they trust the owner of the API making the
refactoring
and the reviewer who doesn't have full access.