On Mon, Aug 25, 2003 at 08:22:34PM +0100, Mark Howard wrote: > Hi, > I've started a discussion on debian-gtk-gnome (galeon not in Debian > stable) about not shipping a package because a stable upstream release > has not been made. There are no major problems with the package, just > minor issues and feature requests. There have been some interesting > responses to this - please take a look at them if you have time. > My initial thoughts were that many minor bugs and wishlist items as well > as a general unpolished feel should stop a package getting into stable. > There are many reasons, however for including galeon. Slightly unpolished is better, IMHO, than leaving a big gaping hole in the distro where galeon used to be. I would certainly miss not having galeon available. > Should we have another measure for when packages are releasable in > addition to RC bugs. For example, does having >100 minor bugs means that a > package is unsuitable for stable? > I know the default answer is that it's the package maintainer's decision > - but I don't know what to decide! Also, saying <200 non-RC bugs might > be a useful QA metric. I think it's common for large packages to have such a large number of bugs. (That, or I'm denial wrt my own capabilities as a maintainer.) They tend to have more bugs not because they're of lower quality, but because they have more users reporting on the minor issues that bother them individually. This makes it hard to develop a concrete metric for when a package is too buggy for inclusion in a stable release -- other than the presence of individual bugs which are considered RC. So my answer is no, there shouldn't be another measure for considering packages unreleasable *in general* besides RC bugs. This doesn't mean you can't request your package's removal if you really feel strongly about it, I would just encourage you to reconsider in this particular instance. -- Steve Langasek postmodern programmer
Attachment:
pgpm6Ur1c2laU.pgp
Description: PGP signature