Re: The future of commit access policy for core Firefox
Mark Côté <[email protected]> Thu, 9 Mar 2017 17:31:52 -0500
| Newsgroups | gmane.comp.mozilla.devel.seamonkey |
|---|---|
| Message-ID | <[email protected]> |
On 2017-03-09 5:19 PM, Lawrence Mandel wrote: > On Thu, Mar 9, 2017 at 5:14 PM, L. David Baron <[email protected]> wrote: > >> On Thursday 2017-03-09 16:53 -0500, Mike Connor wrote: >>> I've identified the following goals as critical for a responsible commit >>> access policy: >> ... >>> - The change that gets pushed must be the same change that was >> approved. >> >> I'm curious what this goal means. In particular, does it mean that >> you're trying to end "review+ if you make the following changes", >> and require that reviewers re-review the revisions no matter what? >> >> (If it does mean that, then that's a substantial increase on >> reviewer load; if it doesn't, then I'm curious what definition of >> "the same" you're using.) >> >>> In order to achieve these goals, I propose that we commit to making the >>> following changes to all Firefox product repositories: >>> >>> >>> - Direct commit access to repositories will be strictly limited to >>> sheriffs and a subset of release engineering. >>> - Any direct commits by these individuals will be limited to fixing >>> bustage that automation misses and handling branch merges. >>> - All other changes will go through an autoland-based workflow. >>> - Developers commit to a staging repository, with scripting that >>> connects the changeset to a Bugzilla attachment, and integrates >>> with review >>> flags. >>> - Reviewers and any other approvers interact with the changeset as >>> today (including ReviewBoard if preferred), with Bugzilla flags as >> the >>> canonical source of truth. >>> - Upon approval, the changeset will be pushed into autoland. >>> - If the push is successful, the change is merged to >> mozilla-central, >>> and the bug updated. >> >> I'm curious if this will mean that ReviewBoard will be required, or >> if it will still be a way to use attachment-based workflows. (I ask >> this because I still consider the ReviewBoard UI unacceptable for >> changes that are likely to require re-review. See >> https://bugzilla.mozilla.org/show_bug.cgi?id=1285874#c20 for my form >> response on the topic, although I've been a little less picky about >> requiring attachments in all cases lately, when I think things >> aren't likely to require multiple rounds of review.) >> > > Mark Cote's team is currently working on enabling autoland from Bugzilla so > MozReview will not be required. Also fwiw we have (finally) made some progress on the bugs you mentioned there. Mark