>>>>> On 29 Nov 1998 14:31:09 -0500, Adam Di Carlo <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> | Blessed Be! @ http://www.ioa.com/~dres | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach
