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!

      

For the first installment in my Ubuntu Developer Interview series, we have Dustin Kirkland, a member of the Ubuntu Server team. As you will see, in each of the interviews, I have some questions that are tailored specifically for each developer, as well as some general interest questions. I hope you enjoy these interviews as much as I have.

How long have you been working with the Ubuntu Server Team?

I officially joined Canonical to work on the Ubuntu Server Team in February of 2008. I’ve been working in and around Linux and open source software since 1998.

How much time do you spend working on Ubuntu?

At least the normal, 40 hour work week, obviously. Beyond that, probably another 10-20 hours per week, working on various other aspects that are outside of the scope of the Server team. That time generally increases around release time and deadlines, as well as when I’m traveling for “sprints”.

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

Well, I’m not quite a core developer yet. My core developer application was just endorsed by the MOTU Council, and next, I will be interviewed in IRC by the Technical Board. It’s a strange, though healthy, difference from what I’m used to. It’s interesting to be grilled in the public. Compared to “promotions” in the private sector, the process in open, and very public. I certainly prefer the public review of one’s work, and as I said, overall I think it’s “healthy”.

Are there any special plans or new features planned for the Server edition of Jaunty?

The Ubuntu Developer Summit is being held in Mountain View, California at Google’s headquarters 2008 December 5 - 9. There, we’ll establish the formal plan for the Jaunty Server.
There are proposals, however. You can view mine under my Blueprints in Launchpad: https://blueprints.launchpad.net/~kirkland

Right now it seems Ubuntu is known primarily as a “Desktop Distro”. What can Ubuntu do to make strides in becoming more accepted in the Datacenter?

That will continue to be our focus during our week of discussions at UDS. I’m hoping to work on some Green Computing initiatives on the Ubuntu server, to establish Ubuntu as the “green” server option. Again, that’s not blessed, or fleshed out entirely yet. But I think there are some obvious things we can do in that respect.

For someone like myself who is interested in helping the Server version of Ubuntu, but also like me lacks any real “programming skills”, is there a way to get involved with the Server team and help out? If so, where could we get started?

Adam Sommer leads the Ubuntu Server Guide documentation project. He’s always looking for some good, technical non-programming help. Developers generally appreciate Ubuntu users who can comb through the bugs in Launchpad, and “Confirm” bugs that they can reproduce, and close
ones that are no longer applicable. Beyond “Confirming”, if you know the packages/code well enough, you can “Triage” the bug against the correct package. That helps developers focus on the pertinent code. And finally, you might be surprised how many bugs can be solved by one or two lines of code–often fixes to shell or perl or python scripts. These don’t require mad programming skills in C or erlang or something.

Is there anything that Ubuntu could learn from the distro’s that are more “established” as “server distro’s”?

There are lessons to be learned, but I think in general, we’re trying to blaze our own trail in the server market. You speak of the Linux desktop… The Linux desktop had been around for almost 10 years before Ubuntu entered the scene. The success Ubuntu established on the desktop was less about learning lessons from other Distros and more about totally re-creating the desktop Linux market.
Ubuntu created more “new” Linux users than it took away from other distributions. The Ubuntu desktop did this by creating the most user-friendly desktop environment, with the most out-of-the-box support for hardware that Linux had ever seen Personally, my goal is not to “win” over Red Hat, or SUSE, or Debian, or Mandriva server users. Rather, I think a better measure of success
would be landing many first-time Linux server administrators, with them choosing Ubuntu over the many options in the market. Especially in the “data center” you mentioned above, I think there’s still market share to be gained against proprietary Unix and Windows servers. And with Cloud Computing taking hold, this world is about to have billions more OS images running in virtual clouds around the world. We’d like some significant number of those to be Ubuntu servers.

Do you contribute to FLOSS (Free/Libre & Open Source Software) in any other ways?

I have written a few open source projects from scratch, most of which are in Launchpad, and couple I’ve packaged for Ubuntu. I’m hoping to package the rest of them for Ubuntu for Jaunty. These include:

• musica - http://launchpad.net/musica (in Intrepid)
• bogosec - http://launchpad.net/bogosec (packaged for Jaunty, awaiting approval)
• pictor - http://launchpad.net/pictor (hopefully Jaunty)
• lynx-web-app - http://launchpad.net/lynx-web-app (hopefully Jaunty)

I’m also the upstream maintainer of ecryptfs-utils, which I’m extending to support encrypting your entire $HOME directory.

• ecryptfs-utils - http://launchpad.net/ecryptfs

I created and continue to maintain the Ubuntu Manpage Repository, an automatically generated collection of all manpages included in supported Ubuntu distributions:

• http://manpages.ubuntu.com/

I developed a Google Custom Search Engine, which is quite useful for Ubuntu developers, testers and community members. It indexes a number of sites that provide useful information and documentation about Ubuntu, including the Official Documentation, Wiki Documentation, Man pages, Launchpad Blueprints, Launchpad Answers, Ubuntu Forums, Ubuntu mailing lists, IRC logs, Package descriptions, Launchpad Bugs, and Source code changelogs.

• http://people.ubuntu.com/~kirkland/search.html

Based on that work, I helped replace the search engined used by:

• https://help.ubuntu.com/

Also, I blog regularly about Ubuntu and open source software at:

• http://blog.dustinkirkland.com

What areas of Ubuntu/Ubuntu Server get you especially excited, i.e., what is your personal passion?

Security, mostly. I love working on new security development and integration within the distribution. I’m hoping to work on encrypted swap, and encrypted home directories for Jaunty.

Now, for some more general questions:

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

My daily machine is a Thinkpad t61p running Intrepid, but I’ll probably upgrade to Jaunty around Alpha 3 or 4.
My wife uses the smaller Thinkpad x61. She’s a teacher, so she runs Edubuntu, and she’s non-technical, so she uses the very stable Hardy 8.04 LTS. When I travel, I swap the hard drives between the t61p and x61, and I take the smaller, lighter, longer-battery x61 on the road.
I also have a MythTV front end in every room of the house. I have five ASUS Pundit P1-AH2, with AMD x2 processors ranging from 3800 - 5800, and 1 - 4 GB of RAM, most of which are running Intrepid. And I have one PowerPC Mac mini MythTV frontend running Hardy. These machines also
double as development, test, and cluster-computing systems.
I have an old, tiny Dell Optiplex SX-260 which is my co-lo backup system at my parent’s house 500 miles away, also running Hardy. And I’m also the lead developer and administrator of DivItUp.com (a free web service for splitting bills with friends/roommates), which is running Hardy in a dedicated VPS VirtualBox.

• https://www.divitup.com

What desktop environment/Window manager do you use?

I think I answered most of this in the previous question…
I use Ubuntu/Gnome on my primary system. My wife uses Gnome under Edubuntu/Gnome. Most of my MythTV frontends use Mythbuntu/XFCE, though I do keep at least one around using Kubuntu/KDE4 (just for my own education).
My MythTV backend (also NFS server) runs Ubuntu server (no desktop manager). And Divitup.com runs Ubuntu server in a dedicated virtual machine.

What applications are key to your everyday computer use?
That’s a tough question to answer without just dumping `dpkg -l`
As soon as I boot into my desktop, I launch:

• gnome-terminal
• firefox
• xchat
• pidgin
• evolution
• liferea

Then, I connect to my musica web server, and pick out some music to listen to. Oddly enough, I still use xmms
There are so many more packages, though, required just to get to the point where I’m ready to launch firefox.
My $HOME directory is encrypted, so I need ecryptfs-utils, and pam to mount it, and about a hundred more just to boot the computer. I can’t do anything without ssh’ing to a dozen different machines. GPG, for signing email and package uploads. Multiple suites of build tools to build the packages I work on. This list could go on all day….

Could you share a screenshot of your setup?

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

Hmm… Get involved! There are many, many aspects of the Ubuntu community, and you can likely find a niche. Development seems to be my niche. Lots of people want to get involved with Documentation. But there’s a lot more than just that. Bug triaging is really valuable. Translations help bring Ubuntu to the far corners of the world. Get involved with your LoCo, and foster the Ubuntu spirit in your community.
Grassroots media and positive public relations, like blogs, and the now-famous The-Matrix-Runs-on-Windows video are so important to our community and success, in that we don’t have Mac-verus-PC commercials airing during the Superbowl or the Olympics. Buy an Ubuntu t-shirt and wear it around. I *always* wear an Ubuntu t-shirt when I fly, and I’ve had dozens of interesting conversations as a result.

Cheers,
:-Dustin

Thanks again Dustin, for taking time to share your knowledge and insight with us!

      

Over the next few days I’ll be posting some interviews I have conducted via e-mail with some of the developers responsible for bringing us Ubuntu. Their answers will bring us insight into what goes into creating and maintaining a popular Linux distribution, as well as great ideas on how to personally get involved in the community.

Stay tuned.