Are you saying that driver rewrite would become any simpler just because kernel interfaces have been changed and now developers need to figure out the new way, to do something that have been already working. Yeah, right.
Let's have a 5 year old argument, the result of which was the inclusion of GPU drivers into the kernel.
We've been here before.
Furthermore just look at Xorg for just why stable apis don't really belong in monolithic designs, part of the entire reason it's so crappy is that it's got a Stable API that they can't touch and thus they've been forced to write extensions to get around the problem (I.E. they have to work around the issues of the X.org protocol). Does this really sound like something that should be happening with the kernel as well? Even Qt which insures ABI and API compatibility over major versions and is modularly designed does breaks which cause the creation of a new major version. Which means even something like it doesn't really have a stable API but a versioned API, which is the only thing you might have an argument for but that falls through due to the monolithic design of the kernel.
Actually X's way of depreciating interfaces is even nicer.... accidentally, quietly, break an interface / API. Someone comes along years later, notices that its been broken for years and no one noticed. The assumption is "Well no ones complained so I guess no one uses that anymore" Then they vocally and deliberately remove that interface/API and that chunk of code is gone lol
But you keep on #TiltingAtWindmills :cool:
1) Github ot other git repo for code upload with hooks for compilation with various configurations. (Did you know that mesa 9.0 wont compile with comands from radeonBuildHowTo? I know. I was told that on IRC after 4h of traying :D)
2) PTS + some defined collection of apps (open source so you can be sure that "testing" code is in fact bug free), for performance testing.
3) Piglit for any regressions in OpenGL that can be detected that way.
4) PTS + games + automated screen shot + diff for images and warnings for too much difference between reference image (taken on Catalyst drivers..), and currently obtained.
5) Whatever you can get for testing delays between following frames.
6) Restoration of "clean" configuration on multiple failed boots.
Everyghtin of above compared to reference (either last stable mesa+kernel+server, or Catalyst, which is better for you).
Oh, and Server that would manage automatic restart of hw/ queuing test request from various developers, and replicating test runs on different hw configurations, as well as managing reporting.