Otavio Salvador wrote: > When I deal with my packages I put that kinda of bug in > 'grave'. Doesn't mind to me if the affected group is 1 or 1k people. > > I'm talking about /bin/sh but it's far from that simple > problem. That's the way people are handling bugs. In my POV the text > that define the 'grave' severity doesn't say that you should ponder on > how many people will be affected by the bug and then that shouldn't be > used as a messure. The definition of grave is "makes the package in question unusable or mostly so". If many people are successfully using the package, then it's not unusable, even if a few people cannot use it. Consider the Debian installer: It's usable by many users to install Debian on a wide array of hardware, but there are some sets of users who cannot use it -- for some people, it's still too hard to use; some hardware (in the past most SATA hardware) won't work; and some setups (like network installs over ppp) are not supported. None of these lacks mean that the Debian installer has a grave bug that should prevent it from being released. A grave bug in the installer is instead one that, for example, makes debootstrap fail halfway through. The number of people affected by a bug does affect its severity -- for sarge, it was reasonable to not consider lack of support for SATA hardware as RC, because the kernel support just wasn't there and clearly wouldn't be for a while, and because the majority of drives were not SATA. For etch, it makes sense to consider SATA issues as RC, because a lot more users will be affected by them. The "or mostly so" in the definition of grave severity is a hint that this severity is not a boolean, but a semi-arbitrary point along a scale. This is why there will from time to time be arguements about whether bugs are grave. -- see shy jo
Attachment:
signature.asc
Description: Digital signature