[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: what needs to be policy?

>>"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

 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.

 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: