Re: The future of commit access policy for core Firefox

Here's a thought to potentially mitigate some of the delays associated with
re-reviewing for nits and rebases: post-commit review. That is, person A
authors the patch, puts it up for review as usual, person R reviews, says
"r+ with nits fixed". Person A can fix nits/rebase/etc and land right away,
but the patch then still requires the re-review by R after landing.
Obviously in the case where no changes are required, we can skip the
post-commit review.

This doesn't fix the total reviewer time spent, but it does fix the extra
(potentially multiple rebase) timezone/round-trip latency for person A.
That being said, it would require tooling support to make sure that reviews
don't get lost and buy-in from people to actually do the post-commit
reviews. In my experience with the QuantumRender work where we tried this,
a number of patches got left behind and without somebody following up on
them they would have been missed. So I'm not sure this option is actually a
good one, but I'll throw it in this thread as something to consider.

Another option is that person R implements the nit fixes and does the
landing instead of bouncing it back to A. This has obvious problems as
well, but again, throwing more ideas out there for the sake of discussion.