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.