This is a personal view on how doxygen bugs in the debian BTS should be prioritized by the debian package maintainer. Of course this is not meant as a policy nor should it be binding on people using the BTS to report bugs.
## 1. Architectures
Upstream provides binaries for Linux x86-64 (“Compiled using Ubuntu 14.04 with kernel 3.13.0 and gcc 4.8.2”), Windows (32-bit and 64-bit) and Mac OS X 10.5+.
Debian provides it on many more architectures besides amd64, but doxygen works there only by pure luck, since upstream is not building for them nor testing it there. I don’t think it’s fair to assume that upstream should respond to an issue related to armhf or mips. Nor is it fair to ask a maintainer to carry the responsibility of porting a 20-years old, 250 kSLOC C++ code-base to 10 new architectures. Consequently only amd64 is really supported, for the other architectures there may be “complimentary” support by the maintainer but nothing more.
## 2. External users versus internal users
According to popcon data, ATM there are at least 8381 debian users (in reality we know they are more, because many people do not send popcon data) and 63586 ubuntu users. Among those users there are the internal users i.e. dds, dms, and anybody who needs it to build the 443 packages that build-depend on doxygen. The external users are the complement. Based on those numbers my estimate is that the external users are one or two orders of magnitude more that the internal users. Consequently the maintainer should give precedence to bugs filed by people who use doxygen directly for the purpose of generating documentation, rather than indirectly for packaging. Also because end users do not always file a bug when their encounter an issue, so their input is extremely valuable.
## 3. What is top-priority
Top-priority in this context is what affects a user's main purpose. As a human, top-priority is remaining alive. As a singer, top-priority is avoid loosing the voice. Out of the metaphor, for external users who use doxygen to create documentation, top-priority is an issue such as a crash that prevents them from generating the documentation. For a dd or a dm, whose main purpose is to produce “the set of basic programs and utilities that make your computer run”, documentation is a nice-to-have (that’s why most -doc packages are recommended not required). Consequently no doxygen crash encountered during a package build should be automatically considered top-priority (in this context).
## 4. Type of issue: point versus structural
An example of point issue is when something weird happens with an exotic Unicode character. Here a precise set of steps to reproduce it will help finding the 1 or 10 LOC that cause it. Overall 1 h to 1 day of focussed work. BTW systematic QC is great at finding point issues. Many seemingly unrelated obscure races, intermittent and non-deterministic issues, occasional invalid output data etc. on the other hand are more often caused by a single structural issue. To address these requires a different approach: analysis with fuzzy testing or valgrind or compiler instrumentation followed by a higher-level design decision such as “refactioring” or “using smart pointers” or “using a different XML library” (these are just examples). Overall 1 day to 1 man-year of work, ideally often interrupted by casual walks and coffee breaks to ease meditation, resulting in 1 week to 5 years of calendar time. Systematic QC here may yield “random” data in the sense that what the QC sees is noise. Keeping track separately of each of these as point issues does not help the analysis. Better group them: Bug A: “obscure race”, Bug B: “intermittent and non-deterministic issue”, Bug C: “occasional invalid output data” etc.
In conclusion, point versus structural issues should be handled differently and within different time frames.
## 5. Bug report quality
A report is more easily handled by the maintainer, the lesser cruft and unnecessary steps it contains. Ideally for doxygen, it should contain the minimal required source code containing doxygen annotations and the precise doxygen command used, that reliably causes the issue. No need to download megabytes of code, to install additional packages or a specific build automation tool, or whatever: happy maintainter !
While this ideal quality is difficult to get from external users, it should be expected from fellow debian project members, who also get reports filed against their own packages.
