Re: Bug#30036: debian-policy could include emacs policy
>>>>> On 29 Nov 1998 14:31:09 -0500, Adam Di Carlo <apharris@burrito.onshore.com> said:
Adam> I still don't really understand what is intended by moving
Adam> sub-policies into the policy manual. Is it intended that the
Adam> Debian Policy group take editorial control over the documents?
Adam> Does the package maintainer lose the ability to change the
Adam> document, unless they are also a policy editor?
Everyone changes policy based on discussion here.
Adam> Are you really sure you want to ask the menu documenter to do
Adam> all the work to split devel-level policy from user
Adam> documentation? I admit its not a bad idea, but...
Don't. Just make a copy in the policy deb.
Adam> I'm just a little worried about this "manifest destiny"
Adam> attitude toward policy, i.e., ever-increasing scope.
I don't think that's the intention here. It is more that 'it would be
nice to be able to install one package and find all the documentation
that is policy for debian. At the moment we have to install at least
three (menu, emacsen-common, and policy) and as more sub policies are
created that will expand. Having all that information in one central
place (even if contained elsewhere as well) is a good thing.
Adam> I stand by my "middle-of-the-road" position that Policy should
Adam> instead *point* to a number of "blessed sub-policies", i.e.,
I don't think that that is being argued here. No one (I've seen) is
saying that the menu policy and the emacsen policy should be inserted
in the appropriate place in the policy doc. Only that the particular
files that describe those two policies should be contained in the
policy _deb_. They don't become a part of the policy manual. They
just gain a place in the policy package (so that when the policy
manual points at that policy it is easily found in the same package).
Adam> the package. This also enables maintaniers of subsystems to
Adam> continue to innovate.
Nothing stops them from doing this. 1) They can change policy be
arguing here. 2) They can change their package and submit a change to
policy for that package (when they are done innovating).
I can't see a common case where the people on policy would reject a
maintainers change to a sub-policy. There surely will be cases, but
those would occur anyway (with or without the document being included
in the policy package).
Adam> The danger of course is that Debian could become hidebound.
Never. Things change. Why do you think debian-policy exists except
to change things. Careful, controlled change when things have started
to slow down, but no control over those quickly changing and getting
better packages. No one has argued either that as soon as a sub
policy begins to take shape that it should be taken over by policy.
Only when it has become stable do we add it to the policy package.
Dres
--
@James LewisMoss <dres@ioa.com> | Blessed Be!
@ http://www.ioa.com/~dres | Linux is kewl!
@"Argue for your limitations and sure enough, they're yours." Bach
Reply to: