Re: Policy rewrite: chs 1 & 2
On Mon, Feb 19, 2001 at 11:06:18PM +1000, Anthony Towns wrote:
> 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,
>
> may -> wishlist; should -> minor/normal/important; must -> serious
Noted, thanks.
> > 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.
OK, accepted. We'll see how to fit it into a rewritten policy. At
present, section 2 ranges from the definition of DFSG through to rules
about maintainer scripts and guidance on error-trapping in makefiles!
(That's something I definitely want to change: reorganise this
material in a slightly more meaningful way.)
> > 2.1.4 The non-free section
> > [...]
> > (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)...
Fair enough. I'll put that bit in, if there are no objections.
> > 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...)
How about something like "...packages in non-free must satisfy all of
the requirements of this policy document. Individual exemptions may
be made if agreement is reached to do this on the debian-policy
mailing list."
> > 2.2 Priorities: important
> > [...]
> > 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?
8-)
> > (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.
Agreed.
> > 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?
libtermcap: no, it isn't. It's impossible to compile against
libtermcap using an up-to-date Debian system.
varargs.h: still useful.
But surely there are lots of other such obsolete constructs and
libraries; we really need a programmer's guide for such things rather
than policy.
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
Debian GNU/Linux Developer, see http://people.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
Reply to: