On 26 Jun 2006, Ian Jackson wrote: > Frank Küster writes ("Re: Bug#375502: debian-policy must clarify how > sub-policies should be managed"): >> For a document called "Debian-Foo-Policy" to be part of The Debian >> Policy it must be included in 1.4. If it is not included there, it >> is not mandatory policy. How is that unclear? > > The list in 1.4 isn't necessarily complete.
I am of the opinion that it is. At least, it is meant to be complete, anything that is official technical policy for Debian should be available when one installs the debian-policy package. >> Otherwise, nobody hinders me to write a document and call it >> "Debian TeX Policy" (or "Debian Shakespeare Policy" or "Debian >> Lesbian Policy" ;-)) and install it with one of my packages. It's >> clear that this doesn't imply any normative value. > > If you write the Debian TeX policy then it's just as normative as > the debian-policy manual. If it's full of nonsense and you refuse > to remove it then someone will complain to the Technical Committee > and the TC will instruct you to remove it from the package. This is not how I interpret the document. I would call the TeX policy document a draft policy, which TeX develoeprs may chose to follow. However, the draft document can change rapidly, without the oversight and the process that this mailing list imposes. When the sub policy is considered mature, it ought to be submitted for inclusion. > For starters, the OCAML policy should be put in some package. But > you should also file a bug asking for 1.4 to be changed to include > it in the list. Following the policy upgrade process, please. On 26 Jun 2006, Frank Küster spake thusly: > Ian Jackson <[EMAIL PROTECTED]> wrote: > >> Frank Küster writes ("Re: Bug#375502: debian-policy must clarify >> how sub-policies should be managed"): >>> I tend to disagree. A sub-policy should only be part of the >>> debian-policy package, and installed in >>> /usr/share/doc/debian-policy, if it is accepted and has been >>> established through the official policy process. >> >> There is no `official policy process'. Manoj has (very wisely IMO) >> abolished the previous bureaucracy and returned to editing the >> manual according to his own judgement - taking into account of >> course the advice and information of others including probably the >> rough consensus of this mailing list. Well, I would have changed the emphasis a bit, but this is somewhat right. I just use the policy process as outlined to help me decide on what the rough consensus is, and to help me assign priorities to the tasks. > Is this really true? Then why hasn't the policy-process document > been deleted from the binary package? And why did we see people > sending "Seconded" messages to this list and counting seconds, > without anybody calling "Hey guys, this is useless"? Umm, this is not quite what I had in mind. There is still a policy process; it allows people other than the policy editors to broach and discuss enhancements to the policy, it allows domain experts to add their voices, and it makes the policy delegate's jobs easier. What has happened is that with formal delegation I think I can act without the full process where the issue appears to have an obvious and clear resolution. While the policy process is still the preferred means of getting policy to be changed, I also am cognizant f the fact of life that people often do not follow the process. Since the policy editors are now delegates, I can afford to not be as anal retentive about bureaucracy as I had been, and can act when the proposal is a clear flaw in policy. I would much rather not have to do this too often, since I, being human, make mistakes (note the cgi-lib fiasco from earlier this year). So please, do follow the process outlined, and feel free to poke me on issues. Also, Marga is working on a set of usertags/usercategories that would help us all categorize bugs on policy, and that would perhaps streamline the process, and help direct our energies where they are most needed. >> So there is no difference in the authoritativeness of the policy in >> debian-policy versus that in any other package. These policies are >> all authoritative I tend to disagree. manoj -- A good supervisor can step on your toes without messing up your shine. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]