Hello, [I'm sending this to three lists. Please only reply to -devel unless the answer is on-topic for some of the others.]
This mail is about making people aware of how actions aimed at improving Debian, like providing a new version of a library or NMUing a package, can have negative effects too, and how can everybody (even the casual -devel reader) help to minimize such effects. For that, I will use what recently happened with vorbis-tools and speex as a example. This is not a personal rant, since I don't use any of the affected software, but I do care about the overall quality of Debian and seeing this things happen saddens me a lot. Which is why I decided to write this e-mail. None of this is about finding out who was at fault, since we all make mistakes. It's just about answering "what can I do better", which I think everybody asks themselves from time to time. * * * The story ========= The Speex library made, among others, the following change between 1.0 and 1.1: its speex.h file moved from /usr/include to /usr/include/speex. After libspeex 1.1 had been uploaded, a new upload of the vorbis-tools package happened (an authorized NMU, to be precise). When this new version was compiled against speex 1.1, the ./configure script failed to detect the availability of speex, and thus disabled speex support. A bug about ogg123 not being able to reproduce .spx files any more was filed at severity important 9 days after the upload (#306809). One month later, a message was sent to d-devel [1] explaining the situation. I read the message a couple days later, and promptly uploaded a NMU to fix (with maintainer's permission). Unfortunately, it was too late for it to be included in Sarge. Net result: ogg123 as shipped in Sarge can't play speex files, while the software is capable of doing so and so was the case during most of the Sarge development cycle. [1] http://lists.debian.org/debian-devel/2005/06/msg00035.html * * * The analysis ============ So let's have a look from several point of views at what can be done better in order to prevent things like this happening, Library maintainers ------------------- Please treat the maintainers of packages build-depending on your library as first-class users. Try to always be aware of what consequences will your acts have for them, and communicate when necessary. For example, for the above change between speex 1.0 and 1.1, a notice could have been sent (and perhaps it was) to the affected maintainers making them aware of the issue. Such notice is best sent in the form of a bug in the BTS, so that other people (e.g., NMUers) can know about the issue too. If you're certain that the issue will bite a package in the next upload, file the bug at severity important or higher. For example: "vorbis-tools: auto-detection of libspeex will fail in the next upload". Coordinate with the Release Team. Package maintainers ------------------- Try to make your build system as robust and deterministic as possible, as in, avoid if possible that it produces different binaries for different sets of installed packages. For example, explicitly using --with-something will make ./configure fail if it can't find it, while not specifying it would just result on the script disabling that part. Know the output of your ./configure script, and baby-sit new builds looking for differences. Even better, use the resulting config.h file: always compare the new one with the previous one. Consider putting it in the source package, e.g. debian/config.h.prev, so that NMUers can benefit from it too. (I don't think this has been proposed before, and makes absolute sense to me.) Run debdiff. Inactive package maintainers ---------------------------- Know your limitations, and file RFH/RFA/O bugs as appropriate. Just welcoming NMUs is not enough, since then you rely on the MIA people discovering someday that your package is unmaintained. NMUers ------ Read the whole list of bugs for the package before you upload, not only the ones you'll be fixing. See above under "Library maintainers" for an example of this being useful. Subscribe to the PTS of the package. This way, you'll become aware of any new bugs you've accidentally introduced (as the mentioned #306809). Run debdiff. Twice. The casual -devel reader ------------------------ If you see a message about an important issue not being handled, try to do something about it. Think whom could you forward it to: the maintainer, the latest uploaders, the maintainers of related packages, an specific mailing list or IRC channel. It's all about finding a developer that will care. If you know that a maintainer is inactive, inform [EMAIL PROTECTED] If he's not inactive, but he's not maintaining a certain package anymore, politely ask him to consider filing a RFH/RFA/O bug for it. * * * And that was all. Thanks for reading and happy hacking. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Listening to: Ellos - Muy pequeño In my opinion, the most fruitful and natural play of the mind is in conversation. I find it sweeter than any other action in life; and if I were forced to choose, I think I would rather lose my sight than my hearing and voice. -- Michel de Montaigne -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]