[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

The story of speex/vorbis-tools, or how not to be disservicing to our users



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 mia@qa.debian.org.
    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



Reply to: