There is one important point here, namely that bugs are very rarely fixed in stable versions.
Here's an example - which happened to me, but is very, very typical, across multiple distros,
and multiple applications.
1. I installed Ubuntu Edgy and Amarok. The media-centre laptop uses a USB sound card. I found
a bug in that Amarok wouldn't let me use OSS with /dev/dsp1. This is a trivial bug to fix
(there is a drop-down list of devices, and no ability to enter your own; I worked around it by
symlinking /dev/sound/dsp to /dev/dsp1)
2. I immediately reported the bug, and the workaround.
3a. What actually happened is *nothing*. The bug has basically been ignored for over a year.
Many other users of Amarok on Edgy will suffer the same bug, and will either have to re-invent
the same workaround, or give up.
As the bug reporter, I wasted my time.
3b. What *should* have happened is this:
* the bug gets fixed promptly upstream (this is the quid-pro-quo of
users sending in bug reports)
* the fixed application gets pushed out into the existing release, so that all users of Edgy
get to benefit.
My point really is that we need to speed up the cycle of
bug - fix - distribute
so that it takes of order weeks, rather than years. Importantly, we must do this for the
ordinary releases, not just the development versions, because most users do not run the
development branch.
Ubuntu and Mandriva get the QA/release stuff mostly right, but once the distro is released to
users, updates almost cease: development attention moves to the next release, and the branch
is almost abandoned, at the very moment it is gaining users! Gentoo get the updates right, but
there's never really a "release". As a result, Linux users can never have a system which has
received both substantial testing, and benefits from all the bug fixes which are upstream.
Posted Jun 15, 2008 0:11 UTC (Sun) by man_ls (subscriber, #15091)
[Link]
Many people (myself included) find Debian testing to have the right combination of bleeding edge and quality that others yearn. Getting the correct blend of packages can be daunting, but once you are there it just works. And is kept updated fairly often. Perfect for a desktop if you ask me.
Quality assurance and Linux?
Posted Jun 15, 2008 9:07 UTC (Sun) by tajyrink (subscriber, #2750)
[Link]
There isn't enough bug fixers, unless eg. you are one who also fixes bugs in addition to
filing them. Maybe one thing then is that Ubuntu has not yet raised enough new volunteer
developers, even though the user base is very big. There are quite a lot of vocal users who
blame Canonical for not fixing a bug (mainly affecting very few persons) filed a year ago, but
the sad truth is that no developer has probably even looked at it - too little information in
the bug report, no patch provided to ease releasing a fix, no discussion ignited (with
solution proposals) on mailing lists etc., and hundreds of these similar bugs which would
require a lot of tinkering because the default user-reported bug is that "it does not work".
There are plans to improve on this, but clearly it needs people fixing bugs, not only
reporting them. Fortunately more of them are appearing too all the time.
Stable release updates also require an amount of testing volunteer developers do not have
resources or willingness to do, except for "now it works for me" which isn't acceptable.
I do think the "Free software only" option is appealing to many, since it brings "Debian main"
level of freedom to Ubuntu in an easy way. Because Ubuntu is based on Debian, and has received
criticism for the driver-related compromises, it's a good thing to be able to show that
"select this and you've essentially DFSG-free distribution".
QUALITY ASSURANCE AND LINUX?
Posted Jun 15, 2008 18:20 UTC (Sun) by jwb (guest, #15467)
[Link]
Why would you expect them to fix a problem with OSS? OSS is dead, dead, dead. Nobody is
going to work on that sort of thing.
hard-coded device filename list
Posted Jun 16, 2008 10:48 UTC (Mon) by ballombe (subscriber, #9523)
[Link]
You are right about OSS being deprecated, of course.
However the concept of a fixed list of device filename to use is a ridiculous idea. Linux
allows to create any device file anywhere in the file system (and symlinks to device files),
and amarok should not restrict that by second-guessing the filesystem.
I had the same problem with kppp and a USB-to-serial converter.