Certain practical constraints guide our selection of which applications to instrument and post here. We welcome your suggestions for additions to the suite, but please keep in mind the following practical issues.
One project member (Ben Liblit) is responsible for building, testing, posting, and supporting all instrumented applications. Ben’s time is finite, and so we must use it in ways that maximize our return (in usable data) for the time we invest.
For this reason, we prefer to post instrumented rebuilds of applications which are already cleanly packaged for their host platform. For Fedora, that means applications which already have RPMs that build and install cleanly, and which pull in a minimum of other non-standard supporting packages. We do not have the manpower to deal with fixing up packages that are broken even before our instrumentor comes along.
The entire concept of this project centers around learning failure patterns from large numbers of runs. Thus, maximizing our return for time invested also requires that we post packages that will attract large numbers of users. The more obscure or specialized a piece of software, the smaller its user base and therefore the longer it will take us to gather enough data. We prefer to post applications that have enough users to let statistical debugging do its magic quickly and effectively.
We would like to support more platforms that just Fedora / i386, including non-Linux operating systems. However, each platform we support requires a build machine here at Bug Isolation Headquarters, and we only have so many machines. Each machine needs a system administrator as well, which gets back to our limited human resources.
We are open to the idea of working with trusted, competent third parties who provide their own build machines. You might build binaries yourself or simply provide machine access for us to use. Contact us if you want to help out in this way.
Our instrumentation strategy and statistical debugging techniques are applicable to a wide variety of programming languages and paradigms. However, our current implementation is for C. We do not yet support C++, C#, Java, Python, Perl, and so on. The ideas still apply, but we don’t have the implementation.
If the current application suite seems to have a GNOME bias, now you know why. Most KDE applications are written in C++, and therefore are out of our reach. Mozilla and Mozilla-based projects (Galeon, Epiphany, Thunderbird, Firebird, etc.) are unavailable for the same reason.
Before suggesting a new application, then, please confirm that it is written in C. Note that we do support multithreaded applications: Evolution, Nautilus, and Rhythmbox make heavy use of threads, and our instrumented rebuilds of these packages work quite well. Furthermore, applications do not need to be graphical or interactive. Batch programs, daemons, command-line tools, and so on can all be instrumented if we hear sufficient demand.