Qt has had an open bug-tracker for a few months now. I am very happy about that. It has made life far more pleasant for Qt developers compared to the past. However, there are some problems. In summary, bug reporters are often treated like the enemy instead of contributors, and this could be fixed easily.

My company, Openismus, provides bugmasters to corporate open source projects such as maemo.org. We know how to make the best use of outside contributions, so enthusiasts stay loyal, and we know how to manage bug databases for the long term. See the overwhelmingly positive feedback for Andre and Karsten, maemo.org’s bugmasters. They acquired these skills while establishing  GNOME’s bug squad, working on GNOME’s huge bug database.

I have linked to some Qt bugs as anecdotal examples of poor interaction with bug reporters. I am not interested in a discussion here of the technical aspects of these bugs. They are not meant to be technically critical. Also, half of them are for QtMobility, whose developers are generally very helpful, but even they haven’t learned the best bug-tracker habits. I don’t think I have seen enough Qt bug reports to have a fully representative sample, but my short experience does suggest that there are serious problems. I don’t mean to exaggerate or be unfair.

Awkward UI

Let’s look at a random bug. This view (not this particular bug) will be the first look at the bug-tracker for many people, as they follow a link to an existing bug. But it does not seem designed for humans. There are some particular problems:

How do I add a comment?

Typically, I’ll read the comments on a bug report to see what’s happening. But then there’s no obvious way to add my own comment. If I look around then I finally see a “Comment on this issue” link nestled among other less important action at the left hand side. I believe that many people won’t find that link, or will be discouraged by the awkwardness. I much prefer just writing a comment right into a bugzilla page.

Noise

The “all” page is too complicated, with lots of machine-generated noise. Instead of fixing that, there are tabs that show reduced views: All, Comments, Work Log, Change History, Transitions. This makes the whole page seem even more complicated.

The all page is so nasty that many people will switch to the comments page. But then comments lose their context. For instance, here (bug 7303) the Qt employee seems to be blaming the reporter though he is really just talking to someone that he has assigned the bug to. I’d rather just see a single page, as in bugzilla, without so much noise. The notification emails are similarly padded with irrelevant details.

Rush to close

We notice a strong tendency for the Qt employees to close bugs at any cost for any arbitrary reason as quickly as possible. Presumably they are under pressure to reduce the simple number of open bugs. But a bug-tracker exists to collect information that can gradually be used to improve software. If you think of everything as short-term and rush to ignore that information then you will not make the improvements and customers will assume that you don’t care.

Hard to check the fix

When I close bugs, I mention at least the commit message that I used. Sometimes I link to the commit’s web page on our gitweb or gitorious. But Qt bugs are often closed with a mention of the git commit ID (such as d65d3becc292523f0962aac9d2bf7b96d9c47c04), with no link. For instance, bug 8865 and bug 5729. I am thankful for the fixes but, particularly for documentation fixes, it’s best if I can verify it and reply quickly.

Viewing the change for a particular commit ID is awkward, requiring lengthy use of the command line outside of the browser. Even the gitorious web site doesn’t let me search for a commit ID, so I have to browse through pages of recent commits using the browsers find-on-page feature.

Actually, the person fixing the bug often cannot provide a gitorious web link at that time because that commit isn’t even public yet, because Qt’s gitorious repository is just a mirror, updated approximately daily from a secret repository. Things would be easier if they just worked in an open repository. In the meantime, Qt’s bug tracker should be hacked to recognize and link commit IDs, showing a “try tomorrow” page if the commit is not yet public.

Not supported. Not public

If the Qt developers decide (after the fact) that something in Qt is not supported then the bug may be closed, instead of leaving it open for someone to fix. But if something is not supported then it shouldn’t be in the release. For instance, bug 7334.

There’s also lots of Qt API that is used widely but not documented. Bug reports about the lack of documentation may be closed instead of leaving it open for someone to fix. But all API should be documented for the sake of implementation quality, regardless of whether it is public. And if API shouldn’t be used then its documentation should say that it shouldn’t be used.

Closing bugs because they require work

Bugs are sometimes closed because they would require effort to fix them. This makes no sense to me. Even if no Qt employee plans to fix them, they should stay open so others can fix them, and so that the information is kept in one bug report, with repeated reports being marked as duplicates. For instance, bug 5915.

Sometimes the idea of necessary work seems to be invented just as a way to close a bug. For instance, in bug 5729, a simple patch is not enough. The reporter is told that he must test it on multiple platforms, ignoring the possibility to test the harmless change widely during regular unstable releases.

For non-employees, the page even has some probably-unintentional machine-generated “You don’t have permission to work on this issue” at the left, just in case the reader didn’t feel unwanted enough already.

Out Of Scope

Likewise, if the Qt developers don’t personally see a problem as their priority then they will sometimes close it as “Out Of Scope”, regardless of whether the reporter cares about it or whether he might provide a patch.

Sometimes (bug 5729 again) this happens without the Qt employee even writing a comment explaining why. This is the bug-tracker equivalent of “Go away. We don’t want you to use our software”. Stopping this should be a top priority.

I’ve also seen one case (bug 6074) where this was used when the Qt developer meant “already fixed”. Until I asked for clarification (most people don’t) I assumed that they just didn’t care.

Can’t reopen bugs.

If a fix is not good enough, or the Qt employee has misunderstood the problem, I can’t reopen the bug. That is very frustrating. Most people will not beg for the bug to be reopened or even bother continuing to comment on the closed bug. Luckily we do have the option to submit gitorious merge requests when our bug has been incorrectly closed. For instance, bug 11496.

Can’t close bugs

There’s also no way for external contributors to close bugs. So Qt gets no outside help with bug triaging. This arbitrary separation between employees and external contributors is an obstacle to open development.

We are comfortably fond of autotools here at Openismus. It’s not perfect but we can use it, it does what we need, and it doesn’t have the problems that we see in other systems.

Autotools Tutorials

Years ago I wrote some popular introductory web pages showing how to do the obvious important stuff. David King has updated them and put the examples in git. They are now even simpler, because autotools got even better in the meantime. I think they will be useful.

Autotools with Qt Creator

Some of us like the Qt Creator IDE. So we asked Peter Penz to create a qt-creator plugin that provides some autotools support making it easier to use qt-creator with lots more existing projects. For instance, you can now have some code-completion in qt-creator with autotools-based projects, and you can run the whole build cycle from inside the IDE. Looking at the code, it seems fairly easy to create these plugins once you know how.

It currently works with the stable qt-creator 1.3 (ignore the uneven version number) though you’ll need to build it from source yourself for now. There is some interest from the qt-creator maintainers, so we hope to find time to update it for qt-creator’s master branch, which uses Qt 4.7 (currently unstable, but eventually stable with the same uneven version number), and then make a proper gitorious merge request.

By default, qt-creator uses qmake, though I think there is some CMake support. qmake is a time-wasting copy/paste-encouraging feature-lacking broken failure, so anything that helps people to avoid it must be good.

After our successful year of training at Openismus, I thought I’d publish the rough bullet-point list that we used. Whoever we choose for the following year will repeat much the same process, with in-depth critique and a dose of reality.

These were our overall aims:

• Familiarity with the programming languages, toolkits, and tools, beyond the average.
• Good quality habits – documentation, ChangeLogs/commit-messages, bug filing, simple code.
• Good communication – politeness, precision, knowing who/where to contact, tracking progress and following up.

And this is the stuff that we checked off along the way:

Knowledge of C

• Respect for memory. True understanding of pointers.
  • Understanding of the many ways to use * and & and [], declaring and dereferencing.
  • Understanding of state (Such as a widget’s data, or a user_data struct, or a C++ class’s member variables.)
  • Understanding function pointers, including their weird syntax, made easier by use of typedefs.
• Basic understanding of object-orientation – Write functions that have a namespaced prefix and that take a first self/this parameter.
  • Write init and free functions where appropriate.
  • Don’t use a prefix that is used by an existing library.
• Use of enums (or defines if necessary, or static constants if appropriate) instead of magic numbers/strings.
• Breaking code up into small blocks, separated by empty lines, with pseudo-code comments above each block. In small functions, of course.
• Initializing local variables, even if you don’t think it’s necessary.
• The GTK+ coding style, which is common for C.

Knowledge of GTK+

Familiarity with GTK+, to the level of implementing new widgets.

• Reference-counting: Conventions and special cases (gstreamer and tinymail use a different convention, for instance).
• Child widgets don’t really use reference-counting. They are destroyed by parents regardless.
• Glade and GtkBuilder
• Implement a new widget, doing some custom drawing and/or containing some child widgets. Make sure that you understand what the various construct/init/finalize/destroy/etc vfuncs do.

Other C stuff and basic tools

• Tools: gdb, valgrind, svn, git, diff, patch.
• Writing ChangeLog entries or commit messages (mentioning files and functions, and what changed in them and why).
• autotools
• gtk-doc syntax, and knowing what developers need to see in the documentation. Mention the what, when, why, how, and “see also”.
• Familiarity with Clutter, to the level of implementing new actors. See the Openismus Clutter tutorial.
• Fix some GNOME bugs, submitting patches. Maybe work with the gnome-love group.

Communication

• Join the relevant GTK+, GNOME, Maemo, and Qt mailing lists.
• Add Openismus employees to your GNOME bugzilla Users To Watch list. Someone will watch yours too.
• Be repeatedly told to file bugs and patches, and to follow up on them. File bugs about documentation too.

Familiarity with C++ – at least the parts used by gtkmm and Qt

This takes more time than anything else, but its doable with motivation and mentoring from our experts.

• Read a full book, such as Accelerated C++, cover to cover.
• Understanding of classes, constructors, inheritance, polymorphism.
• Understanding of references.
• Understanding of const and mutable.
• Templates. And template specializations.
• Use of std containers.
• Familiarity with gtkmm (easy because they know GTK+ already.)
• The gtkmm coding style, which is common for C++.
• The doxygen/javadoc syntax.
• Wrap some new GTK+ API for gtkmm.
• Fix a Glom bug. For instance, there are some simple Glom gnome-love bugs.
• Familiarity with Qt. Understand what moc does. Do something real-world with it’s (quasi) model/view widgets. Understand QString historical oddities.
• Maybe find a bug to fix in KDE.

Optimization work

• Understanding processing, memory, and IO costs.
• Avoiding premature optimization while avoiding obvious performance errors.
• Using Oprofile, SysProf, system tap, etc.

Debian/Ubuntu packaging

• Package a new version of an existing package, such as Glom, in the Openismus PPA.
• Package something new for Ubuntu.

Embedded Linux

• Use of Scratchbox with Maemo.
  • Port something to Maemo.
  • Package it for maemo-extras.
• Using a BeagleBoard:
  • Set up the BeagleBoard and get something running.
  • Try to install Mer.
  • Putting a self-built distro on generic hardware (BeagleBoard), using Poky or OpenEmbedded.
• Be aware of differences/pros/cons between Poky and OpenEmbedded.
• Document how a customer might prepare and maintain a custom debian (or Ubuntu) distro for their embedded hardware project. For instance, how to install and use an autobuilder for packages.