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>>
> 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.
More information about the Mir-devel