

Is a bug RC relevant if it has an influence on the health of a person - bigstorm
http://lists.debian.org/debian-devel/2010/09/msg00207.html

======
_delirium
Somehow getting this from a Debian stable version to begin with doesn't make
much sense to me. If I were using software where bugs could lead to death, I
would hope I'd track any bugfix releases myself and retrieve them directly
from the vendor as soon as they came out.

I mean, it still makes sense to give it a freeze exception so they don't ship
a seriously buggy version with a stable release, but I would _also_ hope that
no doctor is relying exclusively on whatever version happens to come with a
particular Debian stable release, without checking on the status of that
version.

------
unwind
If it isn't obvious (it wasn't, for me), "RC" in this context means Release-
Critical.

Here (<http://bugs.debian.org/release-critical/>) is a handy graph showing
Debian's trends for the number of open RC bugs.

------
Tyrannosaurs
From a process perspective I'm not sure what the benefits of conservative
processes are if they result in shipping an effectively unusable or dangerous
product, nor indeed the point of a definition of "release critical" if
releases happen anyway (with in excess of 1000 "release critical" issues).

My background is very much in commercial software rather that FOSS. Could
someone explain why Debian ships something as niche as this with it in the
first place? Isn't that the equivalent of Windows shipping with, say, Sage
Accounting in just in case someone wants to use that?

~~~
aristidb
It is not installed by default. The way it works, Debian provides you with
many thousand of packages which you can install with one command. Debian makes
sure that all programs and libraries work together, and that nothing is
downloaded more often than necessary (by factoring out dependencies).

This approach works very well, but it has a few shortcomings, including the
fact that sometimes, Debian ships a somewhat outdated version of a package,
which may contain bugs. Some bug fixes, such as security updates, are pushed
to users, but "non-critical" bug fixes need to wait.

~~~
_delirium
In particular, that approach is quite nice for servers. If you're on a
particular Debian stable release, you know that anything you install will work
with the same base set of packages, and any security updates will work as
drop-in replacements. You're never going to find that installing a new package
suddenly triggers a set of cascading upgrades as it pulls in newer versions of
libraries and other packages. If something depends on MySQL, it'll be the
version of MySQL in the Debian you're using, and you won't be forced to do an
unplanned MySQL upgrade in order to install the package. Then you can do
planned, infrequent upgrades between the major releases, when you upgrade from
one Debian version to another.

(Not that Debian's unique in that. FreeBSD's release branches and Red Hat
Enterprise Linux use a similar model.)

------
steveklabnik
As brought up in the Reddit thread, this is about getting the new version that
has the fix into debian, not 'should we fix this or not.'

~~~
csmeder
What is the argument against putting it into debian? I am not familiar with
RC.

~~~
raphman
Debian has just entered a hard package freeze to prepare for the next release
(Squeeze). This means that no new packages may transition from "unstable"
(where they are uploaded to) into "testing" (which will become the next stable
release soon). If a package in testing has a release-critical (RC) bug, the
release managers may make an exception and allow a new, bug-fixed upload to
transition into testing. If this is not deemed sensible, the package is
completely removed from testing until Squeeze has been released. The package
will still be available in unstable.

