Re: The case for rewriting the Policy document (Debconf7 proposal)
Manoj Srivastava <email@example.com> wrote:
> There are far too many policy documents. The main technical
> policy, the Perl policy, the MIME policy, the emacs policy, the menu
> policy, the python policy .... indeed, I can't come up with an
> exhaustive list; which is a problem if I were to create a package
> governed by one of the missing policy documents. We need some place
> where _all_ the policy manuals that may govern package creation are
I agree that this is a problem, but I've been told that it is a feature,
too: It allows teams to develop their sub-policies while they are in
use and not yet graved in stone.
If we want to change that, maybe there should be an easier way to get
"into" formal policy. Maybe based on the severity levels?
I assume that this will be made easier by the docbook structure you
suggested, because then the very differing form(at) of sub-policies is
no longer a problem.
> Each policy rule can be an XML/SGML entity; and have clearly
> defined the severity (MUST/SHOULD/MAY); the _topic_ it belongs to; the
> normative part, the rationale, and the check.
I'm not sure that a check is possible in each case. On the other hand,
an additional attribute/field could be an "implementation suggestion".
This could just point to dh_foo, or to a more complex setup, and give
someone who rarely touches a package in that "topic area" an easy means
to conform to policy.
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)