Manoj Srivastava <[EMAIL PROTECTED]> 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 > listed.
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. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
