On Thu, Nov 12, 2015 at 10:32 PM, Manish Goregaokar <manishsm...@gmail.com> wrote:
> There are actually two kinds of trust involved. First is the trust to not > botnet the CI, basically > everyone here (at least everyone with try) has that. > I think there's an important trust distinction between try and core repo access - try lets you botnet the CI, but that is a very intentional, detectable, and low-stakes compared with intentionally or unintentionally introducing a security vulnerability or architectural flaw in the core engine. But I agree with you that this isn't the distinction that matters so much here. But that's not the actual one being discussed > here. The second is not really a form of "trust", rather it's the level of > familiarity involved in > the codebase to know the areas of code where small changes may cause big > problems. > Or being experienced enough to know what you don't know. Familiarity with the code matters, but I think judgement and sensitivity to social norms probably matter more. > For example, I > would probably ask for re-review on rebases of my own changes to layout > code or bindings code. Often > a PR is to an area of code where stuff is straightforward and there's very > little chances for things > to mess up, which is where delegate+ comes in. Other times it may be in an > area which some things > need to be done precisely, and a rebase needs review -- but it's not > always possible to tell these > areas apart at first glance. Reviewers have the "trust" that they know > when review-carry is > appropriate. The debate boils down to whether or not everyone has this > kind of "trust". > Exactly. I think that limiting this trust to reviewers is too restrictive in practice, costing us more than we realize and buying us less than we think. But I think those arguments have been reasonably-well-fleshed-out, so I won't belabor them here. :-) Cheers, bholley _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
