On Sun, Feb 20, 2000 at 07:43:58PM -0200, Henrique M Holschuh wrote: > I really like the idea of a new RC bug severity, equivalent to "normal" but > with the "this bug makes the package unaceptable in the stable distribution > due to quality assurance reasons" connotation. That should make things much > simpler for the bug submitter. But which `normal' bugs make a package unacceptable in the stable distribution? How is a maintainer or a user meant to know about these in advance, either to know what to expect when writing the program, or when trying to build a system that works for him? Also, doesn't this definition apply equally well to bugs that should be classed as critical or grave? ``Login doesn't ask for a password!'' certainly makes the package unaccepatable in the stable distribution due to quality assurance reasons. We've got some-hundred of maintainers and who-knows how many thousands of users, having them each work out their own definition of what's `acceptable' or not is just a recipe for confusion. Here are some things I think are legitimately important, based on a browse of policy: * Package in main requires something outside of main to build or run (2.1.2) * Package in main/contrib is not DFSG-free (2.1.2/2.1.3) * Package in non-free is not distributable (2.1.4) * Package not in non-US contains crypto code (2.1.5) * Package doesn't include accurate copyright info (2.1.6) * Package depends on lower-priority package (2.2) * Package has incomplete dependencies (2.3.4) * Package cannot be built from source (2.4) * Build-Dependencies are incorrect (2.4.2) [0] * Package doesn't have a changelog (2.4.4.) * Package's changelog isn't recognisable by dpkg (2.4.4) * Package doesn't comply with FHS (3.1.1) * Package does not use update-rc.d and init.d correctly (3.3) * Program names conflict (4.1) * Library not compiled correctly (4.2/4.3) * Shared library not packaged correctly (libfoo, libfoo-dev) (4.3) Note that `package is uninstallable' bugs (postinst is broken, dependencies can't be met) are grave bugs ("makes the package unusable"). So, like I said, perhaps `severe policy violations' should be one objective criterion for `important' bugs. There are probably others, too. `package is not 8-bit clean' sounds a lot like a policy violation, although it's obviously not in Debian's policy doc. Should it be? Cheers, aj [0] `incorrect' as opposed to `incomplete'. Until woody, there's not much cause for worrying about packages whose maintainers haven't gotten around to making up a build-depends list yet. -- Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds
Attachment:
pgpwEixiNDJyz.pgp
Description: PGP signature