The X server must ideally cooperate with with open and closed ATI, NVIDIA and Intel cards, but not forget those from smaller providers, a fact that becomes most noticeable to users when they're sitting in front of blank screens instead of the desktop. The call for help from Ubuntu users keeps coming to Harrington as bug reports on Launchpad.

Now Harrington is calling for help himself. His graph of bug reports for Karmic Koala in recent weeks "literally went off the chart," which prompted him to recommend concrete steps to avoid future X.org problems.

Where do these bugs come from? The increase in bug reports is for Harrington not so much an indicator that X.org is qualitatively poor, but that lately more users are reporting bugs. Some of the bugs are truly emerging from the new GDM2, the dynamic kernel module support (DKMS) and upstart, which most recently took over coordinating the Ubuntu boot process. The new features didn't cause altogether that many new bugs so much as make existing ones worse, although there were enough stable release updates (SRUs) to deal with the worst cases.

Suggestion 1: hold off on upgrades. Harrington offers the possibility for the future of waiting for the first wave of patches to come in before having the update-manager recommend upgrades to users. At least users who are trying to keep their systems up to date can then enjoy some stability. He suggests the same for LTS as for Lucid.

Suggestion 2: a new testing model. The volume of bug reports is also causing Harrington headaches in terms of his workload. He's had to concentrate on Ubuntu 10.04 for time and personal reasons, even though X.org work is still continuing on the current Ubuntu. Although he'd like to be conservative with X.org, major changes to the X infrastructure are probably needed. HAL will be dropped, Radeon is getting kernel mode setting (KMS), and NVIDIA and ATI driver installations are being rearchitected. There is also a move underway from -nv to -nouveau+kms drivers.

Harrington therefore suggests putting together a desktop testing team, with "a smaller number of people who just
commit to running the same sequence of test steps say once a week." The results will then clearly show where improvements and degradations are emerging. Once the number of successful tests starts decreasing is when bug reports should be written at high priority so as to fix the problems. For Harrington, the solution would be better than filling an already overloaded bugtracking system.

Will this help? Harrington's idea makes sense if indeed a fixed release cycle doesn't allow a large spectrum of users to test the system effectively. To find bugs at all, the project needs tons of users testing the finished Ubuntu. Harrington thus wants new users and early adopters to take a crack at it so that the general Ubuntu user will have an SRU to work with.

Experimental users are responsible themselves for moving early to a "stabile" Ubuntu version. New users don't notice any problems because they don't run into them, or when they do, they currently send in bug reports and repair their systems via updates. Better yet, they uninstall Ubuntu and revert to Windows/Mac or another Linux version. As it currently stands, the Ubuntu project in the worst case might run into both scenarios.

In view of these changes, the project has to ask itself, however, "is it really impossible to thoroughly test the Ubuntu version to avoid these problems before its release?"