Size of Optional - policy and name for new Priority
It's clear that Optional is far too large. Although we nominally say
that packages for which you need to have a special requirement before
you want to install them should go in Extra, this rule hasn't been
well enforced, and is in any case contentious.
We need a new Priority level distinction, which subdivides Optional,
such that most people will want to install all packages in the `better
half' of old Optional.
I suggest that we adopt something like the following set of rules for
the new priority (I'll call it Better for now):
* Usually only one package meeting a particular user requirement will
be Better. When there are competing popular versions of a program,
two might be Better. Three should be rare.
* Better Packages should be easy to install; they should be stable,
have simple installation procedures so that they are very likely to
install without problems, and should adhere even more strongly to our
rule that packages should not ask configuration questions unless
absolutely necessary. Complexity in installation scripts etc. must be
justified.
* Better Packages should not impair system security. A strong case
will have to be made for programs which are setuid, include daemons
which run as root, or which listen on network ports. (setgid games
and perhaps certain other exceptions might be made.)
* Better Packages should justify the disk space, network bandwidth,
and installation time they take up. So, large packages need much
better justifications than small ones.
* Justification should be based on the proportion of users who are
actually expected to want to run the program, and how much of a
benefit that program is to them compared to alternatives (or not
having a similar program at all).
* Better packages should already be widely used (as Debian packages or
in the wider community), unless they fill a gaping hole.
* The set of Better packages should be decided upon by a small group.
This group needs to have strong support from the project leadership
when they make decisions which a maintainer disagrees with. No
package should be accepted into the archive as Better without human
intervention by this group - at least, someone other than the
maintainer. I'd suggest that Project Leader appoint the group, who
could also adjudicate other disputes about priorities.
This new category needs a new name. Currently `Extra' and `Optional'
already seem very close, so there seems no `room' for another term
there. So, the new Priority should be between Standard and Optional.
Ideas I have had so far are:
Usual
Common
Better
Good
Useful
Widespread
Commended
I think it's very important that the ranking of the new Priority
compared to the others needs to be easily guessed.
There is a possible problem with heavily value-laden terms, in that
package maintainers may feel more inclined to claim that their
packages are `useful' or whatever.
Note that `Recommended', an otherwise good suggestion, is already used
as `Recommend' for something else.
Ian.
Reply to: