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

[Jesse Barnes]

On Sun, 4 Aug 2013 22:17:47 +0200
Daniel Vetter <daniel at ffwll.ch> wrote:
> Imo the "unpredictable upstream" vs. "high quality kernel support in
> upstream" is a false dichotomy. Afaics the "unpredictability" is _because_
> I am not willing to compromise on decent quality. I still claim that
> upstreaming is a fairly predictable thing (whithin some bounds of how well
> some tasks can be estimated up-front without doing some research or
> prototyping), and the blocker here is our mediocre project tracking.

Well, I definitely disagree here.  With our current (and recent past)
processes, we've generally ended up with lots of hw support landing
well after parts start shipping, and the quality hasn't been high (in
terms of user reported bugs) despite all the delay.  So while our code
might look pretty, the fact is that it's late, and has hard to debug
low level bugs (RC6, semaphores, etc).

<rant>
It's fairly easy to add support for hardware well after it ships, and
in a substandard way (e.g. hard power features disabled because we
can't figure them out because the hw debug folks have moved on).  If we
want to keep doing that, fine, but I'd really like us to do better and
catch the hard bugs *before* hw ships, and make sure it's solid and
complete *before* users get it.  But maybe that's just me.  Maybe
treating our driver like any other RE or "best effort" Linux driver is
the right way to go.  If so, fine, let's just not change anything.
</rant>

> My approach here has been to be a royal jerk about test coverage for new
> features and blocking stuff if a regression isn't tackled in time. People
> scream all around, but it seems to work and we're imo getting to a "farly
> decent regression handling" point. I also try to push for enabling
> features across platforms (if the hw should work the same way) in the name
> of increased test coverage. That one seems to be less effective (e.g. fbc
> for hsw only ...).

But code that isn't upstream *WON'T BE TESTED* reasonably.  So if
you're waiting for all tests to be written before going upstream, all
you're doing is delaying the bug reports that will inevitably come in,
both from new test programs and from general usage. On top of that, if
someone is trying to refactor at the same time, things just become a
mess with all sorts of regressions introduced that weren't an issue
with the original patchset...

-- 
Jesse Barnes, Intel Open Source Technology Center