What we'd really like to see is, essentially, reaching feature and stability parity with what the R600-class GPUs are currently enjoying with r600g, months before the card's official retail launch. Months, because it takes that long for distros to grab the changes into a release.
I know you said "solid open source driver support", so are you referring to the situation in my first paragraph, or more along the lines of the latter situation? I'm not trolling or expecting more than is achievable here; I just want to know your honest opinion as to what you believe can be accomplished if the open source team is involved from the very start.
Also, since so much important work goes into the driver from non-AMD employees, hopefully you'll be able to provide reference boards to people like Dave Airlie and Marek Olsak, months before official retail availability. Either that, or hire on more developers to do work on the new ASICs before general availability in lieu of the spectacular work by non-AMD employees. Without that extra community help, you're gonna need more in-house manpower, or else find a way to enlist that community help in the pre-release stages.
To meet the lofty goal of "solid" open source support on launch day, you'd really have to up the ante on this whole process. That initial 15,000 line commit would have to land a good 6 - 8 months ahead of general availability, followed shortly by getting reference boards out to anyone from the community you've managed to enlist for help. Then you need to coordinate between the community, your own developers, and the distros, to try and squeeze the driver into the release schedule of the distros currently in development. This can be a real pain if the timing works out poorly; if your driver support is on the rise just as the big distros are putting on the brakes on the release cycle, they may push back at you for making too big of a change, too late in the game for them. And of course nobody expects you to time your releases so they're in sync with Ubuntu releases.
You also have to contend with the Linux kernel release cycle, since you pretty much have to get your DRM changes into a merge window 6 months before you want to see it in a distro. And that's if you get lucky and the kernel release gets picked up by the distro during the development cycle; sometimes a kernel is released later in the cycle and not picked up by the distro.
All in all, conservatively, the current development process of distros and the Linux kernel would require you to get that initial code into mainline starting about 8 months before the card's general availability. That's a really lofty goal to reach, I think, and much more demanding of proper foresight than any other platform. On Windows (or on Linux with fglrx for that matter), you can literally write 50% of your code a month before GA and still be able to get a Catalyst release pushed out to the website before GA. Huge difference, 1 month vs (conservatively) 8.
Now that I've analyzed the release cycle this way, I feel awfully cynical about this. Even if AMD technically "does their job" and gets a solid, well-working driver into Linux git and fd.o git by release day, it'll still be between 6 months and a year before mainstream users can just install a stable distro and benefit from that. This situation is extremely frustrating. I wish we could do something about it. It's highly unacceptable.
The problem is just the release cycles and the way they conflict, I guess. Getting things into mesa on time for a release; getting things into the kernel on time; getting both mesa and the kernel rolled into a distro release over the heads of cautious package maintainers. Nobody wants to be responsible for breaking anything, so everyone just sits on their hands until code has been out in the open for a year or so. That's too long, when you're upgrading your graphics card every 2 - 3 years.
What I'd really like to see is some distros proactively working with AMD and community Mesa developers to pull in as much recent, known-to-work code as possible into a release, going as far as backporting DRM to the distro's chosen kernel version, and doing a distro build of Mesa based on a git commit rather than a stable release (mesa stables are way too few and far between IMHO). Instead of being reactive and just idly pulling in the latest stable release each cycle (yawn, boring), distros should be proactive and try to get the latest and greatest code that they can, provided that it's been tested and developers are on-hand to fix any issues that crop up. If you had this kind of close cooperation with Ubuntu and Fedora and OpenSUSE, you could give yourselves a bit less of a head cramp with the 8 month lead time, cutting it down to maybe 3 or 4 months. That would give you more time to write the driver, and allow for late-breaking hardware changes that require driver changes. And then you might even be able to get supported drivers out to the distros by release day...!!!
It's a dream I've been chasing for a long time, but realistically I'll probably be compiling from git until such time as I retire from the PC gaming scene and have no more use for a current graphics card.