On Mon, Feb 19, 2001 at 12:19:36PM +0000, Julian Gilbey wrote:
> 1.1 Comparison of must, should, may with bug severities: at present,
> the text matches "important" with "must" or "required" and
> "normal" with "should" or "recommended". But now the bug
> severities have changed; there is a new "serious" severity, so
> where does that fit in to the general scheme?
may -> wishlist; should -> minor/normal/important; must -> serious
> 2.1 The aims of this policy are....
> Is this really the case? Surely this is the aim of Debian
> itself, not of the technical policy? The aim of the policy is
> primarily to ensure a high technical quality and very high levels
> of software interoperability, including ease of installation,
> upgrading and use of the system.
It's the aim of section 2 of policy, which are the guidelines on what
software we'll distribute (viz, anything we're allowed to), and how
we'll distribute it (viz, in a way that encourages everyone to write
free software, and in a way that makes it easy for people to produce CDs).
s/We want to /to allow us to/g might be a reasonable rewriting.
> 2.1.4 The non-free section
> It would be nice to clarify this. Can we add the following:
> Packages in non-free or non-US/non-free must meet all policy
> requirements presented in this manual.
> (It does not necessarily make sense to talk about buggy, as we
> may well not have the source code to fix them.)
If it's so buggy we refuse to support it, we should just get rid of it
from the archive (as we did with majordomo some time ago, iirc)...
> Would we have to exclude certain policy requirements for non-free
> packages? I would tend to think not, but I may have overlooked
> some.
djbdns (and qmail?) people might like to be able to upload a non-FHS
package to non-free, and get away with it. I think it's more appropriate
to make special exemptions if we *really* need to, than generalise policy
to cope with non-policy conformant packages. (``We want to encourage
everyone to write free software'' after all...)
> 2.2 Priorities
> According to the text, the priority levels are recognised by
> dpkg. But AFAIK, this is not true; they are only recognised by
> higher level software such as dselect and apt. Comments?
*shrug*
> 2.2 Priorities: important
> The text says:
> Important programs, including those which one would expect to
> find on any Unix-like system. If the expectation is that an
> experienced Unix person who found it missing would say `What the
> F*!@<+ is going on, where is `foo'', it must be in `important'.
> This is an important criterion because we are trying to produce,
> amongst other things, a free Unix. ...
> Two questions:
> (i) Should we write the sentence "If the expectation..." in a
> slightly more formal way?!
Why? Is there something particularly desirable about boring documentation?
> (ii) Is the sentence "This is an important criterion..." relevant
> to the policy document? It's a project goal, not a
> technical policy, surely?
It's rationale for the techincal policy. It may be more appropriate in
a footnote these days.
> 2.4.6 Obsolete contructs and libraries
> Is this relevant to policy any more? It is impossible to compile
> against libtermcap any longer, as the files do not exist. It is
> still possible, though, to use varargs.h. But these appear to be
> two randomly selected examples of software which has been
> superceded. Maybe there should be an appendix with such
> information, but it's not so useful unless it's kept up to date.
It's more useful than if it wasn't there at all, though, isn't it?
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
Attachment:
pgpG1pREuC8Pr.pgp
Description: PGP signature