Interview with Bryce Harrington: Ubuntu Xorg Maintainer

For the second installment in my Ubuntu Developer Interview series, we have Bryce Harrington, Ubuntu’s Xorg Maintainer. Bryce gives us some valuable insight into one of the most complex and important areas of a modern Desktop Linux Distribution.

How long have you been maintaining Xorg for Ubuntu?

I joined Canonical in May 2007 as their Xorg maintainer.

How much time do you spend working on Ubuntu?

Roughly 30 hrs per week on X.org in the distro Ubuntu, and another 30 hrs per week on X.org issues for Canonical’s hardware partners.

How would you describe the path from getting started in the community to becoming a core developer?

It was actually quite a bit easier than I’d anticipated. A lot of the process involves learning *how* to contribute to Ubuntu - learning the toolsets, policies, procedures, etc. The best way to achieve this is to dive in and get practice.
The best time to get practice is right now, well before feature freeze. This is because there is a LOT of fairly newbie-friendly merge work to be done and lots of opportunity to gain practice. Of course, it takes more than just doing a bunch of merges; what I did was make a checklist of packaging techniques I hadn’t ever done before, and made sure to do each of those tasks at least a few times. Once I’d cleared that checklist, I felt myself ready to apply for core-dev.

Are there any special plans for Xorg in Jaunty?

We’ve incorporated a huge amount of new architecture into Ubuntu’s Xorg over the past few releases, thanks to all the intensive work by upstream. In Jaunty, I want to place our focus on stabilization and polish.
We’ve got several plans relating to config tools under way, building on Alberto Milone’s work with x-kit. Wacom tablet support has gotten quite a bit of visibility; our incorporation of input-hotplug last release did not solve wacom tablet issues, so we’d like to take a deeper look into this one area for Jaunty.
To support stabilization work, I’ve been working on an XSmoke test suite - nothing fancy, just a simple way to run a few basic ‘does it work’ checks in a repeatable process.
Another stabilization-focused tool is a ‘historical driver package’ page, which provides i386 and amd64 .debs of git snapshots of upstream drivers going back through time. This will provide a convenient and simple way for users and testers to test older versions, without the need for learning git-bisect or package building. The tool is geared for regressions, to enable users to help isolate when the regression began - this info is invaluable to upstream for narrowing down what patch to revert or fix. Changing the -ati driver from XAA to EXA is also planned for Jaunty. I’ve been very happy to see the progress made by upstream for the -ati driver, and it sounds like EXA has stabilized very well and may be ready for us to adopt as the default. We’ve gained anecdotal evidence that EXA solves a wide number of glitchy behaviors that users have been seeing with XAA. We will be working with upstream to ensure that the EXA changeover goes smoothly and that issues users discover with it get forwarded upstream. Intrepid users can start helping on this right now, by switching to “EXA” in their xorg.conf and filing bugs on noteworthy issues they find.

We all know Intel is great in regards to Open Source graphics drivers, and I’ve read that AMD/ATI is coming around to being more open source friendly as well. How much easier does it make your job when proprietary drivers are not required?

Sadly, with proprietary drivers the Ubuntu X team can’t really do much more than just forward along the bug reports, and hope the vendor will review them.
Open source drivers give us a lot more options for what we can do at the distro level. We can look up error messages to get a better clue what the error means. We can look at the driver’s internal hardware support lists (and sometimes even add to them). With crashes, when we have a full backtrace we can look and see what logic led to the crash (and sometimes even sort out a patch immediately). We can add quirks for non-standards-compliant monitors or incorrectly integrated graphics components. We can add or tweak default values of config options to enable or disable functionality to provide users with better features, stronger stability, or higher performance. We can rebuild drivers for newer or older xservers, and use them in ways upstream may not have thought about before. If we don’t know how to solve an issue, we can forward it upstream, and when they fix it we have the option to selectively backport the patch on a case-by-case basis.
We don’t always have *time* to do all these things, but at least with open source drivers we have the opportunity. Upstream also values when we do this since it helps them know what changes are worth doing.
Open *processes* are in many ways just as important as having source code published under a FOSS license. This includes sharing information openly, transparency into development processes, public bug tracking and source control, participating in the larger community, and so on. It is heartening to see companies like AMD and VIA joining Intel in making progress towards adopting all these practices.

What ways would you recommend for someone who, like myself is not a programmer, but wants to get involved in the community and contribute to Ubuntu?

There is a laundry list of ways non-coders can contribute. This is actually one of my favorite questions, and I’ve blogged on it far more than I probably should!

Let me pick just one idea that probably hasn’t gotten a lot of visibility before but that is extremely valuable at improving Ubuntu’s quality, and go into a bit of detail. I’ll apologize up front for the length!

Forwarding bug reports upstream
A pretty large chunk of bug reports that Ubuntu gets are actually upstream issues. Because Ubuntu is a popular distro we get really good hardware testing coverage, and this can be quite valuable to upstreams in making their software robust. Most upstreams don’t use launchpad so unfortunately they won’t see this feedback unless we push it to them.
I think many of us have had experience with bug reports sitting unaddressed in launchpad for long periods; pushing them upstream can be an effective way at getting attention to them.
Bug-forwarding is basically one link in the bug-report-lifecycle:

1. Reporting
2. Triage
3. Analysis
4. A: Forward  B: Fix locally
5. Package fix
6. Deploy fix

Ubuntu developers have #5/#6 pretty well down to a science. And thanks to great work by the community and Canonical we’ve gotten a lot better at #1, #2, and #3, but #4a is currently a bottleneck since fewer people are participating in it.
Developers like myself try to cover #4a, but if we could get more community members involved in handling it, then it’d free the developers to do more of #4b.

I can give some tips on effective bug forwarding as well. First is how to find bugs to triage. I typically do a query on bugs marked Confirmed or Triaged, Not Reported Upstream, and sort by most recently changed first. This tends to result in bugs most ready for upstreaming at the top.
Always doublecheck that the bug has been tested against a relatively recent release of the software. Upstream tends to be understandably less interested in bugs already fixed in newer releases.
Next, I always make sure that the launchpad bug includes all relevant information, including log files, backtraces, etc. Usually not all of this info needs to be included when upstreaming, so I pick out the relevant files that show error messages or other info upstream will want.
I like to re-state the problem in 2-3 sentences up top in the bug report description. Sometimes bug reports can be a bit rambly or unclear, and having a clear statement helps upstream developers identify bugs they wish to work on. In some (rare) cases, I may need to rewrite the entire bug report to clarify it, especially when the problem only came to light after a lengthy series of comments.
I include a URL back to the launchpad bug in the upstream bug description as well, both for upstream and my own reference. In the launchpad bug, I click “Also affects project” and place the upstream bug URL there.
Finally, I put a comment into the launchpad bug asking the reporter to subscribe to the upstream bug report, in case upstream has further questions or needs someone to test something. If upstream produces a patch, then the next step would be to grab the patch and attach it to the bug report. This flags step #5 to proceed.
And that’s pretty much it. I adopt a practice of forwarding at least one bug each day. Forwarding a bug typically takes about 30 min, although it take take additional time to locate a bug that really is ready to be upstreamed (especially in packages that don’t get much attention from bug triagers).
I would suggest picking one package to focus forwarding efforts on. This allows you to build up experience at what upstream expects, to become good at spotting the difference between user errors, packaging errors, and legitimate upstream problems. You’ll also find that as you build a good relationship with the upstream developers, and they trust you as a good forwarder, they’ll become more responsive and you’ll grow more effective at making Ubuntu (and really all of Linux) better and better.

Will we ever see dual head configuration be a seamless process regardless of graphics chipset (just as it is on other platforms)?

Actually, I think a lot of the remaining glitches (like having to use the Virtual option) are gated on getting the new memory manager (aka GEM). The memory manager is a pre-requisite that really can’t be gotten around, but also something that needs plenty of development time to ensure it’s robust and ready for prime time. Bugs in the memory management layer are no one’s idea of a fun time!
With the new memory manager in place, we then wait for support for using it to be incorporated by each of the video drivers. This is still a work in progress, and will probably need additional stabilization time before it’s ready to be flipped on by default. In Jaunty perhaps we can ship some of this turned off by default, that adventuresome users can opt-in for so they can help in evaluating it. Then maybe Jaunty+1 we can flip it on by default.
Once that’s in place, we can discard the workarounds for setting up the “Virtual” option, which I suspect is where the “seams” are most visible. It also opens us up to being able to do >2 heads, as well as doing DRI (and compiz) with large combined resolutions. Lots of other nifty things become possible after that. Probably lots of bugs too…many opportunities for people to participate in the Xorg bug upstreaming process.

What kinds of computers do you have personally that you use daily?

• Dell XPS P4 desktop, with dual 24″ BENQ LCD’s: Main desktop in office.
• Dell Inspiron 1420N laptop, i965: For when I’m not in my office.
• Self-built Intel Core2 Quad CPU w/ i965 + RV630: Development/build box. Runs my chroots, build daemons, test harness, report generation tools, etc.
• I’ve also got a mythtv backend box with a pretty beefy RAID setup, although I recently switched to FIOS which has reduced the mythtv box to be just a fancy NFS server.
• Then I’ve got a pile of desktop systems used for testing various things, connected to an 8-port rack-mountable KVM. These aren’t used day-to-day, just when there’s a particular bug I’m trying to sort out.

What desktop environment/Window manager do you use?

Standard Ubuntu GNOME environment, principly so it’s easier to spot bugs and reproduce issues users report.

What applications are key to your everyday computer use?

Aside from firefox and xchat, I mostly use console applications. Not that I dislike GUI’s, but I find console programs easier to customize. procmail and spamassassin are key tools for me to stay atop my email inflow. For browsing email I use a pretty heavily customized mutt, which is especially handy during intensive bug triage sessions. For bug triaging in firefox, I’ve been finding greasemonkey to be quite useful at customizing launchpad; we’ve collected a number of GM scripts here.  I’m also enjoying using launchpadlib for making bug triaging tools. I’m slowly collecting these into a project called Arsenal; it’s still quite early on in development, but it’s already helping me stay atop the influx of Xorg bug reports.

Could you share a screenshot of your setup?

I don’t do any special customization of the desktop itself (usually it’scovered in xterm’s). On the right you see the LCD monitor and keyboard for the KVM which is offscreen, along with all that hardware.

The desk is self-built. I’m currently putting the finishing touches on a matching window sill that will also serve as a mount point for all the monitors.

Note the EeePC on the left. This photo is from about a year ago when I lent one to evaluate, well before all the netbook work that came subsequently.

(Awesome setup Bryce! - Jayson)

Do you think there ever will be a “year of Linux on the Desktop”? In other words Ubuntu is getting closer and closer to being considered a “Mainstream Operating System”, especially due to the work done by Dell. Do you think Ubuntu will ever be truly “Mainstream”?

I guess it’s really dramatic to think of suddenly everyone in the world giving proprietary vendors the finger and reinstalling their desktops with Linux. But no, I don’t think there will be a “year” of Linux on the Desktop. I think there will be a number of different isolated but interrelated events over a period of time which gradually push Linux adoption higher and further. The most stunning achievements will be in areas beyond the traditional desktop, but the desktop will be won only at the point where the commercial players no longer care about it. I think it must be won by a major grassroots effort.
My wife and mother both run Ubuntu exclusively. My father is asking for a Dell Mini 9 netbook with Ubuntu for Christmas; my father-in-law is considering getting a Dell laptop with Ubuntu (his first laptop!) I don’t have any non-Linux machines in my house. I tell anyone that asks me for computer help, that I’m happy to give tech support *if* they run Ubuntu, but otherwise they’re on their own; I haven’t used Windows in years and don’t really have the skill or time to support it, even if I had the interest. With Ubuntu, most of the work is just setting it up initially and tutoring the user; it runs reliably and support questions are of the nice “Now how do I do…” variety.
I hope that a lot of my fellow geeks take this Christmas as a great opportunity to take advantage of Dell’s wonderful Ubuntu work, as a way to spread Ubuntu’s presence through their family. A happy Ubuntu using family member can be an excellent source of word-of-mouth converts.
I’m noticing that the increasing number of hardware vendors shipping Linux is having a secondary beneficial effect - more now than every before we’re seeing Ubuntu deployed in production environments which require much more intensive QA/testing procedures than is seen through ordinary community uses. For example, a FOSS user like me might be happy as punch if their laptop’s suspend/resume works 95% of the time, but a hardware vendor is going to test doing hundreds of suspend/resume cycles and will expect *no* errors. I think this type of testing will wring out a class of bugs that don’t typically get as much attention. A trend I anticipate is the growth of Ubuntu in special-purpose devices, beyond the handheld/general-computing use case that the netbook market

is currently pursuing. Think the Tivo model, but for something that would mostly live in your kitchen or garage. Maybe it operates your lights and sprinkler system in a more efficient way, or you plug your camera into it to recharge and automatically download and process your photos, or it reads RFID tags from groceries you bring in and suggests recipes you could make. I think once consumer-product manufacturers start seeing Ubuntu as a reliable, inexpensive platform to build from, we’ll see an explosion of Linux-based devices hitting the market. Longer term, I think the coming recession/depression is going to be a major growth opportunity for Linux and Ubuntu. Many proprietary-only companies are going to have a tough time staying in business and will slow down the development and shipping of new proprietary products. Meanwhile, customers will be looking for ways to cut costs while improving productivity, and will see open source as a big opportunity. Newly unemployed engineers will seek to start up new companies with products having open source  underpinnings; other unemployed people suddenly finding ample time on their hands will use open source participation as a way to hone their skills for their next job. All of this will be really interesting but won’t win the desktop. The thing that’ll gain us the desktop is if every community member makes an effort to convert their friends and family, ensure they have a good experience, and encourage them to spread word-of-mouth about Ubuntu.

Could you tell us a little bit about your other project, Inkscape?

Being consumed by Ubuntu/Xorg work I’ve not really beein as involved in Inkscape as I used to be, but thankfully there are many community members hard at work on it. A lot of effort has been going into refactoring the codebase to switch to using Cairo as the backend renderer, and 2Geom as the computational geometry layer. Inkscape has been ported to a number of other non-Linux platforms on which it’s become exceptionally popular. In a way, this popularity is a two-edged sword, because platform portability issues seem to crop up a lot more in the discussion fora now.
I’d love to hear more cases of users finding Inkscape as a “gateway drug” into trying other FOSS applications, and eventually make the switch to Linux. At the same time I worry that porting Inkscape to non-Linux platforms is just making it easier for people to avoid needing to change, in order to benefit from open source apps.

Is there anything else you would like to share with my readers? Witty comments? Sound advice? Funny stories?

Yes, I want to pimp the Ubuntu-X website. It’s a one-stop-shop for tips on configuring, troubleshooting, and participating in Xorg for Ubuntu:

• http://wiki.ubuntu.com/X/

If you run into an X problem on Ubuntu, go there for help. If you don’t find help, it’s a wiki, so when you do discover a solution please add it there so we can build up the knowledgebase.
Bryce

Thanks again Bryce for sharing your time, insight and wisdom with us!