On Sat, 27 Jul 2013 09:13:38 +1000 Dave Airlie <airlied@xxxxxxxxx> wrote: > > > > 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 Some of this is driven by me, because I have one main goal in mind in getting our code upstream: I want high quality kernel support for our products upstream and released, in an official Linus release, before the product ships. That gives OSVs and other downstream consumers of the code a chance to get the bits and be ready when products start rolling out. Without a bounded time process for getting bits upstream, that can't happen. That's why I was trying to encourage reviewers to provide specific feedback, since vague feedback is more likely to leave a patchset in the doldrums and de-motivate the author. I think the "slowing things down" may hurt more than it helps here. For example all the time Paulo spends on refactoring and rebasing his PC8 stuff is time he could have spent on HSW bugs instead. Likewise with Ben's stuff (and there the rebasing is actually reducing quality rather than increasing it, at least from a bug perspective). -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
