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