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

[Dave Airlie]

>
> Hey, overall it's actually quite a bit of fun.
>
> I do agree that QA is really important for a fastpaced process, but
> it's also not the only peace to get something in. Review (both of the
> patch itself but also of  the test coverage) catches a lot of issues,
> and in many cases not the same ones as QA would. Especially if the
> testcoverage of a new feature is less than stellar, which imo is still
> the case for gem due to the tons of finickle cornercases.

Just my 2c worth on this topic, since I like the current process, and
I believe making it too formal is probably going to make things suck
too much.

I'd rather Daniel was slowing you guys down up front more, I don't
give a crap about Intel project management or personal manager relying
on getting features merged when, I do care that you engineers when you
merge something generally get transferred 100% onto something else and
don't react strongly enough to issues on older code you have created
that either have lain dormant since patches merged or are regressions
since patches merged. So I believe the slowing down of merging
features gives a better chance of QA or other random devs of finding
the misc regressions while you are still focused on the code and
hitting the long term bugs that you guys rarely get resourced to fix
unless I threaten to stop pulling stuff.

So whatever Daniel says goes as far as I'm concerned, if I even
suspect he's taken some internal Intel pressure to merge some feature,
I'm going to stop pulling from him faster than I stopped pulling from
the previous maintainers :-), so yeah engineers should be prepared to
backup what they post even if Daniel is wrong, but on the other hand
they need to demonstrate they understand the code they are pushing and
sometimes with ppgtt and contexts I'm not sure anyone really
understands how the hw works let alone the sw :-P

Dave.