I’ve been reading things people report in Bugzilla for years. How I feel about this now is that there are really several, entirely different things that we presently lump under “bug”. For example, I think it’s pretty clear that someone’s random ideas for a change to the design are totally different from say identified code regressions, which are in turn different from proposed patches.

Given that I am only one human and can’t respond to every bug, much less actually fix them, I’ve had to invent a prioritization mechanism. Note this is in my upstream GNOME role – I do work on Red Hat Enterprise Linux too, and there my priorities are obviously influenced by customers, management etc.

My goal in upstream is simply to make good Free Software. Thus, prioritization I’ve settled on looks something like this:

• Is the bug reporter an important Free Software contributor to anywhere in the stack? Then the bug is important. If they’re also an engineer or knowledgable tester, then things are ideal because I can expect them to try things out and help me debug.
• Is the bug a valid regression with enough data to debug it? For example, “I upgraded from GNOME 3.0 to 3.2, and application foo crashes with this stack trace…”. Then it’s important. Ideally it’s bisected – something I’d like to make easier for both developers and testers.
• Is the bug something embarrassing? For example, badly leaking memory. Then it’s important.

Obviously, a bug could be all three of these things – e.g. a Mozilla hacker could report a regression in GNOME that causes us to leak memory. Then it’d demand a reply =) Things beyond this though get fuzzy. One thing that’s important to keep in mind is that GNOME does not have a business model that scales directly per user. Someone new using GNOME doesn’t necessarily mean there are more people working on it able to respond to, diagnose, and fix bugs. This is why as upstream, I focus so much on the things above – Free Software contributors (in some form) and unintentional regressions.

Why regressions? Well, I obviously have no obligation to someone who just happens to use and deploy my software for free – it’s not like we can e.g. work perfectly on all hardware in all situations. But it important for anyone contributing a change to the FOSS pool to make sure that while their change may take a step forward, it’s not taking two steps backward somewhere else.

I apply that rule strongly even to myself – while I don’t personally care about OpenBSD, I took the time to diagnose a regression I introduced, following the principles above. Hopefully others feel the same!

So I’m at the GNOME Summit in Montreal, and so far it’s looking good. We have a lot of sessions lined up, and a good collection of core GNOME hackers here, along with some interested outsiders.

One thing that’s been on my mind a bit is that I’m now approaching about 10 years of contributing to GNOME. Now, GNOME is two things – the people, and the code. We have a lot of good code, and some bad code. But when I originally got involved, it was more the people, probably most by Havoc Pennington. He’s one of those rare people that had a grasp of a lot of issues, and can both write well-reasoned English, and also write a lot of good code.

What I hope to do by both action and word is pass down to the next generation of GNOME hackers that are coming in now some of those principles and ideas that have guided the project, and heavily influenced me. Havoc’s blog has a lot of good stuff – I’d start with his Free Software UI post.

If you know me, then you also know that I really care about quality in Free Software. One thing Havoc doesn’t explicitly mention is that many preferences and settings (and system state) interact with other preferences and settings. In the GNOME 2 days for example, we just never figured out how upgrades would work if you customized the panel at all. For example, if you moved the clock, what would happen if a UI redesign integrated the clock closely with another applet? There’s a huge intersection of concerns here, and in practice it was entirely possible after upgrades you’d get a half-state between the two. It was gross.

In particular, what I as a software engineer live in mortal fear of is combinatorial explosion. The number of possible states exponentially grows as options and system states change, and that kind of thing makes QA and testing near-impossible. Besides just being bad UI, it makes the entire system buggy. And to me, that’s not what GNOME is about, because I’m following in the footsteps of those who came before.