On Sun, 4 Aug 2013 22:17:47 +0200 Daniel Vetter <daniel@xxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
