From:  Ehsan Akhgari <ehsan.akhgari@gmail.com>
Date:  15 Mar 2017 22:53:12 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.planning
Subject:  

Re: The future of commit access policy for core Firefox

NNTP-Posting-Host:  63.245.214.181

On 2017-03-13 4:38 PM, Mike Connor wrote:
> On Mon, Mar 13, 2017 at 4:35 PM, Bobby Holley  wrote:
> 
>> On Mon, Mar 13, 2017 at 1:24 PM, Lawrence Mandel 
>> 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.

I feel like I'm starting to reply to every message in this thread with
"rebases, rebases, rebases".  ;-)

More seriously, what Lawrence is asking for is simply just impossible.
You can't know what the final patch you will push will be before you
push it due to the fact that we prohibit pushing more than one head, so
you may have to do an unlimited number of rebases before you actually
succeed in landing your patch.

Once your patch has landed, then pulsebot already sends a link to the
landed commit to the bug, and that is what has to be counted on as the
actual source of truth as to what needs to landed.  The fact that
MozReview is incapable of reflecting that in its UI is just a deficiency
of the review tool which we could fix.  I use Phabricator for
contributing to LLVM, and there as soon as I manage to push the final
version of my patch to their SVN repo, Phabricator UI links my review
page to the real SVN revision landed (example:
https://reviews.llvm.org/D16761 says
"Was committed in r260265, but reverted in r260536.")