Is a bug RC relevant if it has an influence on the health of a person(lists.debian.org)
lists.debian.org
Is a bug RC relevant if it has an influence on the health of a person
http://lists.debian.org/debian-devel/2010/09/msg00207.html
10 comments
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.
Here (http://bugs.debian.org/release-critical/) is a handy graph showing Debian's trends for the number of open RC bugs.
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?
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?
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.
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.
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.)
(Not that Debian's unique in that. FreeBSD's release branches and Red Hat Enterprise Linux use a similar model.)
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.'
What is the argument against putting it into debian? I am not familiar with RC.
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.
[deleted]
I'm not an absolute authority on this, but Debian is very conservative with packages, especially on non-testing releases. I believe the problem in this instance was that the bug, while serious, wasn't fixed until the next major version of gnumed, and so they generally wouldn't update the package. Due to the severity, this is a plea for an exception.
That's my rough understanding.
That's my rough understanding.
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.