Quick approval

Daniel van Vugt daniel.van.vugt at canonical.com
Wed Jul 10 02:42:41 UTC 2013

I agree that sometimes land-it-now-and-fix-it-later is the fastest path 
to quality. I'm not sure how to gauge when that holds true...

I am however sure that I've seen many merge proposals where it was only 
the 2nd, 3rd or 4th reviewer who spotted serious issues, that the prior 
reviewers missed. If we catch those issues in review then it takes hours 
or days to fix. If we let them land then we might not find the problem 
for weeks or months.

On 10/07/13 10:26, Robert Ancell wrote:
> On Wed, Jul 10, 2013 at 2:16 PM, Daniel van Vugt
> <daniel.van.vugt at canonical.com <mailto:daniel.van.vugt at canonical.com>>
> wrote:
>     Waiting a bit longer won't affect throughput of landings, only latency.
> That is only true if each change is independent, and I'd assert that's
> not the case.
> Note, if we take too much time to make each merge perfect we lose
> agility. If a merge improves the current codebase then it is worth
> merging regardless of how much better you could make it. You can always
> make a second merge proposal to build on the previous one.
> --Robert

More information about the Mir-devel mailing list