Re: Bug#375502: debian-policy must clarify how sub-policies should be managed
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
>> 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
> 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@example.com> 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
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.
A good supervisor can step on your toes without messing up your shine.
Manoj Srivastava <firstname.lastname@example.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C