Re: The future of commit access policy for core Firefox

On Mon, Mar 13, 2017 at 4:35 PM, Bobby Holley <[email protected]> wrote:

> On Mon, Mar 13, 2017 at 1:24 PM, Lawrence Mandel <[email protected]>
> wrote:
>
> > One issue with r+ with nits that we ran into last year is that the
> > resulting patch/diff is often committed directly to the repo and not
> > uploaded back to Bugzilla or MozReview. This makes it difficult to audit
> > the changes to the repo. Keeping the review system in sync with what
> lands
> > (regardless of the review requirements) will make it easier to automate a
> > repo audit and reduce the time that our reviewers need to spend looking
> at
> > code changes in the audit scenario. Any concerns with making it a
> > requirement that the final patch/diff is documented in the bug/review
> tool
> > rather than landing directly?
> >
>
> Submitting the final patches to two places instead of one seems like
> busywork to me, and I don't do it (even though some do). I don't know what
> it buys us, given that pulsebot posts the hashes of the pushed changes in
> the bug.
>
> So I would object to this.


I'd agree that posting a bug to two places is a non-starter.  That's a
problem we can and should solve with automation. It should be possible to
commit to somewhere, have it show up in Bugzilla, and have it land where it
needs to go.

-- Mike