How to get more people involved in improving X.org for Ubuntu? [closed]
The reason X doesn't get alot of work is that it requires an enormous amount of knowledge about how GPU's, memory etc.. work as well as familiarity with the X.org code base and to some extent kernel programming. It's not a trivial thing to get into and from a community perspective those who are interested in working on X or X drivers are probably already doing so. There is currently no motivation for a developer for developer to work on Xorg aside from personal interest.
The thing that the community has which X.org developers don't necessarily have, is access to a wide variety of hardware. Having people who are willing to spend the time to write 'good' bug reports and test drivers and parts of the Xorg stack before a release is probably going to help the engineers more than anything.
Currently there is an Xorg edgers repo which I use to test drivers on my stable system. It's pretty easy to roll back a single package after i'm done testing. However the only other way we can test is to either build X yourself or to install the edgers repository which builds from upstream. This does a wholesale X replacement as far as i can tell. This means it's an all or nothing approach to testing X.
Having a way to have 2 versions of X ( and fairly easily choose) which one you want to use would allow testers to not only test X , but subsequently get back to a working Xorg so they can submit the bug report.
Speaking as a developer who is casually interested in X, here are my issues:
I only have access to a handful of graphics cards and I suspect most people only have access to one. Thus I can't do much for the vast majority of bugs, which will always be on "some other card".
Unlike most packages, I can't trivially create a test environment for a new driver version; virtual machines have their own X drivers.
I can't easily update to the latest driver, test it out, then revert. This discourages experimentation (because if something goes wrong I might as well be bricked); it also hinders regression testing.
Last time I looked, successfully applying a patch, compiling and running X was difficult to do, stepped all over the package manager, required kernel modules to be patched as well, and was pretty much an irreversible step.
Nowadays, X drivers split their code between kernel, Mesa, udev (for settings and defaults), and userland drivers. Which means patches get split as well...
So I guess the answer is to make applying and reverting changes something that is handled by the package manager and easy to recover from when it breaks your system.
Also, a system like DKMS should be looked at for X drivers; if I could easily patch/compile/test/uninstall, say, the input driver for my touchscreen without having to rebuild the whole monolithic contraption (with its threat of making X completely unusable), you'd get more casual contribution and motivate me to look at triaging bugs and testing patches relating to that bit of hardware.
Well like everything a lot of it is making it easy and accessible for people to find out about it. So from what I remember with bug triage originally there wasn't a lot of help coming from the community. Then when some wiki pages explaining the regular processes in triaging bugs and some bug days got a lot more community members involved. Also if you can start a regular activity for the community to do and offer help to those that try it you will get some interest.
If you need help with the activity you can email me and ill help with organizing it.
So my answer is making a wiki page with questions and commands for getting good bug triage info to get people involved in that.
For development its a big problem. Xorg and Kernel stuff require low level programming skills for most bug fixing and implementing features. So you have to target a specific group of programmers and get them interested. I dont have any suggestions here except ask around a bit and see who hangs out in #ubuntu-x and ask them if they can help.
To complement what jbowtie said, I would add that, as a bug triager, I find X bugs very challenging to deal with, simply because X is a very complex beast. This is reflected in the complexity of the troubleshooting wiki page. What would definitely help is a sort of mentorship program for BugSquad members to learn how to deal with X bugs better. Maybe do a bug hug day around it? Or a hands-on training session in #ubuntu-classroom?