>>>>> On 20 Jan 1999 21:31:57 -0600, Manoj Srivastava <[EMAIL PROTECTED]> said:
Manoj> Hi, >>> "Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes: Wichert> As maintainer of modutils I would find it troublesome if I Wichert> have to go through the new-policy-process here for every Wichert> change I make. Having to wait a while for each feature I add Wichert> doesn't sound very helpful. Manoj> FUD. If you are changing things in a incompatible fashion Manoj> and Manoj> breaking other packages and policy, I sure hope t put Manoj> additional obstacles in your path. In fact, this is a prime Manoj> argument for putting sub policies under the policy change Manoj> mechanism. This is the one thing that makes me want sub-policies an actual part of policy (after the period of quick changes that occur as something is being developed, and everyone agrees a sub-policy shouldn't become policy until after this period). What I'd like a code writer for a subpolicy to be able to do is 1) change things in a backwards compatible fashion in any way they like (so new features are ok. and a new interface is ok as long as the old interface still works as well). And 2) if incompatible changes must be made agreement from all the developers that use that policy must be gotten before making the change (well maybe not all. a certain percentage possibly. that's a detail to be worked out later). This gives subpolicy code writers maximum flexibility, but restrains them from breaking a whole bunch of other packages `just because they wanted to do it differently'. I also like the idea of subpolicys actually being a part of policy so that all policy is together, but I think that the code writers for particular parts of policy should have more editorial control over the sections that they influence (within the bounds of 1 and 2 above). They can add a new interface and add that to the policy and even say that it is now the prefered interface as long as all old interfaces continue to work WITHOUT going through the whole policy change process on debian-policy. This, I think, is the big rub. People don't want to go through a month long siege on debian-policy to add something to their code. I wouldn't either (if I actually had code implementing a subpolicy which I don't). They shouldn't be required to unless they are breaking other packages and even then they shouldn't have to get debian-policies permission just the people who use the policy (which should hopefully be a less painful process). Now of course there are policies that are more wide ranging. Menu is a good example. In this case it'd likely be easier to start the conversation on debian-policy for a large backwards-incompatible change rather than contact the developers for all the packages that use menu. This is also an acceptable option IMO. But things like the emacsen policy where only 20 or so packages depend upon it at the moment it'd be easier to contact just those 20 developers. And it'd be fine just to do that. Why must debian-policy become involved when the change is very localized. Ah well... I'm just repeating what others have said before, but I hope it does some good. :) 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
