In article <[EMAIL PROTECTED]>, James LewisMoss <[EMAIL PROTECTED]> writes: > Everyone changes policy based on discussion here.
Um, kinda. You have to go though a whole *process*. Is Manoj proposing that this process be applied to these sub-policies. No clear answer yet... 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. That would be silly, a bit, since much of the menu sub-policy is utterly irrelevant qua policy. Adam> I'm just a little worried about this "manifest destiny" attitude Adam> 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. If the idea is that the Policy maintenance practices (i.e., submision, seconders, etc.) be applied to sub-policies, this is an ever-increasing sphere of responsiblity for the Policy Group and I can hardly see how you can deny that. 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). You utterly miss the point. What I am questioning is the application of the current practices for changing policy to these sub-policies. The same document, another document, the same package, another package, those are mere details and logistics. 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). This seems weak to me. I'm sorry. Look, I love the new system for maintaining Policy. I lobbied hard for it. But this system is *barely* able to keep up with the course of changes for the Packaging Manual and the Debian Policy. You can try to deny this is true but it is. Bugs are stacking up. Manoj has done a terrific job -- but why does he have to do it alone? Manoj went on vacation and nothing got done. Until the Policy Maintenance teams gets a little wider in depth, and shows they can turn around a greater volume of changes in the same or shorter time, I think any discussion of increasing the duties of the Policy Editors should be shelfed as impracticable. 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. Your asking to take control over from the maintainer/author of the pacakge and documents, and give it to a clearly overworked and under-coping Policy Editor system. I agree with your basic tenants: * all policy should be taken seriously; edits to it should be taken seriously and reviewed by this group and the Policy change control system should be applied to it * all policy should be readable in one, well-defined area. But I just don't think we're ready for this step. Maybe once all bugs older than 90 days are dealt with, I'll feel happier. Is it time to fire the current Policy Editors other than Manoj and hire new ones? If not, why not? qI don't mean to be harsh, but I think overextending the current practices will destroy them, and I don't want that. -- .....Adam Di [EMAIL PROTECTED]<URL:http://www.onShore.com/>
