Re: what needs to be policy?
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.
FUD. If you are changing things in a incompatible fashion and
breaking other packages and policy, I sure hope t put additional
obstacles in your path. In fact, this is a prime argument for
putting sub policies under the policy change mechanism.
What goes into the policy should not be the manual of the
program; rather, it should be the interface that other packages need
to rely on and conform to.
New features would not impact policy, and would not be a part
of policy either; and you are free to change it, and cooperating
packages are free to use the enhancements as they will. However, when
you want to make it policy, you should come here -- I think no one
person should be able to make changes in their package and make
several other packages suddenly be in violation of policy.
Once the interface has stabilized, any incompatible changes
should be strongly deprecated, and going though the policy mechanism
is the least of the hoops one should have to jump through.
Once something becomes policy, the policy is the standard --
the implementation can then be buggy, and non-conformant, the policy
itself would not be considered wrong. In the early days, C was what
the compiler from AT&T compiled. The language was defined by the
implementation. Now, the language spec is stable, and a standard; and
compilers may be defective, and the language is not defined by the
compiler.
Wichert> Is it really that bad to delegate subpolicies to people? I
Wichert> don't really see why the menu-structure can't be delegated
Wichert> to the maintainer of menu for example.
The menu maintainer should not have the power to make all
other packages suddenly be in violation of policy. Are you really
envisaging incompatible changes occuring in menu? If so, please let
me know, I would consider that a grave bug in menu.
>> I do not remember who it was that said that. What were the
>> reasons for not extending policy so that we incorporate conventions
>> that allow packages to cooperate, without fear that one fine day
>> everything may stop working, since the convention is not policy?
Wichert> I vaguely remember someone (Raul?) saying that subpolicies
Wichert> are subpolicies, and as such not part of the debian-policy
Wichert> package.
Either they are debian policy, or they are not. If they are
not, then one may dismiss bug reports based on not following
them. You can't have it both ways. If they are indeed policy, I want
to insulate the packages required to follow policy against the whims
of the current maintainer.
Wichert> After some thought I think I agree with that. Having a list of
Wichert> subpolicies and put that in debian-policy and delegating those
Wichert> subpolicies sounds like a good approach.
Wichert> Wichert. (waiting for Manoj to oppose to a lot of this :)
I would hate to disappoint you.
manoj
--
As long as the answer is right, who cares if the question is wrong?
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: