> On Nov 11, 2015, at 8:31 PM, Bobby Holley <bobbyhol...@gmail.com> wrote: > > On Wed, Nov 11, 2015 at 4:22 PM, Lars Bergstrom <larsb...@mozilla.com> wrote: > I've been assuming the only time that we would use `delegate` is for > people like you (Bobby), whom we trust, but who have not gone through > the process to become a Servo reviewer. > > Sure. From a personal standpoint, my ask here is to make that decision > explicit and global, rather than leaving it per-(reviewer, PR), because I > want to remove these (minor) barriers to my productivity. > > From a project standpoint, I am trying to blaze the trail of the > committer-but-not-reviewer role, because I think it can be a useful one - for > example, Ms2ger did a ton of great work on Gecko in this capacity back in the > day. I have a personal preference for not doing a bunch of Servo reviews > right now (mostly related to the 6-8 Gecko modules where I'm currently > shirking my review obligations). And while I'm sure I could review a few > token patches and cajole people into making me a reviewer, I'd rather > advocate to improve support for this role and remove barriers that I think > are unnecessary. If that fails, I'll probably resort to cajoling. ;-)
This is a compelling argument. If we have bits of process that come from my (possibly totally misguided/irrational) conservatism and that are discouraging contributions, you’re right that we should make it easier. I think that, in practice, the level of trust that we currently have for contributors with “try” access is nearly identical to the level of trust you’re mentioning for these committers. Perhaps we should combine those two. GitHub’s model of providing access to the Big Green Button to anybody that we want to be able to label issues is unfortunate, and I’d try to separate any governance decisions we make from GH’s enterprise-focused featureset. We can do some stuff to make GH less dangerous (e.g., the button is disabled unless all of the GH Status API-reporting tests are passing, which includes homu!), but even that doesn’t prevent doing a blind `git push` to upstream/master. At least `push -f` is disabled, though, so people can’t stealth-rewrite history :-) > On Nov 12, 2015, at 1:11 AM, Bobby Holley <bobbyhol...@gmail.com> wrote: > >> On Wed, Nov 11, 2015 at 10:59 PM, Nicholas Nethercote >> <n.netherc...@gmail.com> wrote: >> On the other hand, I'm more optimistic than bholley about the per-bug >> delegation. Given that it's been implemented I'd suggest using it and >> if reviewers do tend to forget it then consider implementing a broader >> mechanism. >> > > To be clear: I think it would probably work ok, but still worse than the > alternative I'm proposing (which requires no additional engineering), and I > don't see how it is advantageous, (since, per my original email, it seems > like we should give someone delegation in any given PR i.f.f. we should give > them delegation in every PR). If the delegation method doesn't relieve these productivity barriers, I’ll withdraw my objections to having some sort of commit access. Pretty sure I’m the only stick-in-the-mud here (or at least the only vocal one!). Thanks to both you and Nick for keeping up the discussion! - Lars _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
