>>"Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:
Anthony> Personally, I don't see putting stuff in policy as removing Anthony> lattitude. See also http://bugs.debian.org/102213 . That has other problems. What may happen then, since policy becomes optional with a note in a README, is that bloat starts being put into policy (providing even more rationale for for ignoring policy with a mere note), and then things spiral down to a point where we shall have to start looking for some enforceable rules. Making policy optional,and using that to include non-technical, trivial, and unnecesary detials into policy is a stupendously bad idea. >> I hereby withdraw the formal objection, though I am still >> opposed to adding what I consider to be unnecesary implemetation >> details to policy. Anthony> Good advice on packaging issues is always helpful, and Anthony> afaict, policy is the best place for it. The I beg to differ. Policy is not a HOWTO manual. Policy is a set of rules that we need to follow to allow integration. Why not go ahead and put into policy indentation rules? How about variable naming conventions? Or insisting on everyone using dbs+debhelper, since it is evident that debhelper at least is wildly popular and debhelper+dbs cover vast majority of packages? Already we have developers who think policy is too large a document to tackle, and merrily abandon craftmanship to letting their their tools ensure compliance and quality. manoj -- The point is, you see, that there is no point in driving yourself mad trying to stop yourself going mad. You might just as well give in and save your sanity for later. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/> 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 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]
