Re: what needs to be policy?
>>>>> On 20 Jan 1999 21:31:57 -0600, Manoj Srivastava <srivasta@golden-gryphon.com> said:
Manoj> Hi,
>>> "Wichert" == Wichert Akkerman <wakkerma@cs.leidenuniv.nl> 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 <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: