[Intel-gfx] Maintainer-review fluff (was: Re: [PATCH 01/12] drm/i915: plumb VM into object operations)

[Dave Airlie]

>
> In the same exaggerated view, Jesse's premises:
> - Actual user/developer testing is more valuable than review and refactoring
>   - Colorary: merging code with bugs is acceptable, we want the bug reports
> - Endless code churn due to review/refactoring may actually introduce
> bugs not present in the first version
>
> Please tell me if I'm wrong.
>
> From my point of view, this is all about tradeoffs and you two stand
> on different positions in these tradeoffs. Example:
> - Time time you save by not doing all the refactoring/bikeshedding can
> be spent doing bug fixing or reviewing/testing someone else's patches.
>   - But the question is: which one is more worth it? An hour
> refactoring/rebasing so the code behaves exactly like $reviewer wants,
> or an hour staring at bugzilla or reviewing/testing patches?
>   - From my point of view, it seems Daniel assumes people will always
> spend 0 time fixing bugs, that's why he requests people so much
> refactoring: the tradeoff slider is completely at one side. But that's
> kind of a vicious/virtuous cycle: the more he increases his "quality
> standards", the more we'll spend time on the refactorings, so we'll
> spend even less time on bugzilla", so Daniel will increase the
> standards even more due to even less time spent on bugzilla, and so
> on.

Here is the thing, before Daniel started making people write tests and
bikeshedding,
people spent 0 time on bugs, I can dig up countless times now I've had
RHEL regressions
that I've had to stop merging code to get anyone to look at.

So Jesse likes to think that people will have more time to look at
bugzilla if they aren't
refactoring patches, but generally I find people will just get moved
onto the next task the
second the code is merged by Daniel, and will fight against taking any
responsibility for
code that is already merged unless hit with a big stick.

This is just ingrained in how people work, doing new shiny stuff is
always more fun than
spending 4 days or weeks to send a one liner patch, so really if
people thinking we just need to merge
most stuff faster is the solution they are delusional, and I'll gladly
stop pulling until they stop.

I've spent 2-3 weeks on single bugs in the graphics stack before and
I'm sure I will again, but the incentive to go
hunting for them generally comes from someone important reporting the
bug, not from a misc bug report
in bugzilla from someone who isn't a monetary concern. So Jesse if you
really believe the team will focus on bugs
2-3 months after the code is merged and drop their priority for
merging whatever cool feature they are on now, then
maybe I'd agree, but so far history has shown this never happens.

Dave.