[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#375502: debian-policy must clarify how sub-policies should be managed



On Monday 26 June 2006 19:10, Ian Jackson wrote:
> George Danchev writes ("Bug#375502: debian-policy must clarify how 
sub-policies should be managed"):
> > The current paragraphs of #1.4, #11.9, #11.9 show perl-policy as
> > a part debian-policy package and emacs-policy as a separate package.
> > I think that all sub-policies should obey same rules, e.g. each of them
> > to be managed in a separate package or within the debian-policy package.
>
> I disagree.  The purpose of having the files in one package or another
> is to make the maintenance as easy as possible.  If it's maintained by
> Manoj it's probably easiest to put it in debian-policy.  If it's
> maintained by (say) the Emacs maintainers then putting it in an Emacs
> policy is fine.

It is a little bit of mess to have debian-policy containing one or several 
sub-policies and more sub-policies in separate packages. But if that is the 
price to have easier maintenance, it is fine with me.

> Of course it is be helpful for the manual in the debian-policy package
> to have appropriate cross-references to the other policy documents.
>
> 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.

If there is no `official policy process' then what justifies the presence of 
policy-process.sgml and /usr/share/doc/debian-policy/policy-process.*  
respectively ?

> 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 (and are all subject to the TC's power to overrule
> the maintainer without a supermajority).

Good. explanation. Any changes to hit the officail debian-policy since 
obviously I'm not the only one being in doubt if these sub-policies are 
autoritative.

-- 
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 



Reply to: