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

Re: what needs to be policy?

	[I am clarifying my view point, so this message too goes to
	debian-devel. Follow ups requested to debian-policy]
>>"Joey" == Joey Hess <joey@kitenet.net> writes:

 Joey> I've been experiencing considerable friction with Manoj on this
 Joey> list

	I would have put it more mildly than that.

 Joey> The question is: What needs to be policy?

 Joey> Specifically, Manoj's point of view seems to be that as we
 Joey> develop programs that tie the system together and are used in
 Joey> many packages (examples are the menu system,
 Joey> update-alternatives, dpkg, etc), the interfaces these programs
 Joey> present eventually assume the weight of policy, and that those
 Joey> interfaces should be codified and included in the policy
 Joey> document.

 Joey> On the other hand, I think that these interfaces need not
 Joey> appear in policy. 

	An example of what I am attempting to get across is the
 current policy for emacsen packages. Putting together an emacs lisp
 package is more than knowing how to use a program; and it goes beyond
 mere interfaces. 

	A mechanism has been put in place for developers to byte
 compile in place for whatever glavour of emacs happens to be
 installed on the target machine, and to do so without haing all the
 flavours installed themselves (which was seen to be putting to much
 burden on the developers). The proposal is still a work in progress,
 with steps being taken to reduce unnecesary byte compilation.

	Without discussing the merits of the emacsen mechanism itself,
 I would like to say that the mechanism requires packages to install
 scripts for byte compilation, and for cleanup, and to place calls to
 common facilities in the pre/post maintainer scripts. 

	Initially, this is indeed tied to the emacsen common package,
 since we are evlving the mechanism, and it is understood that early
 on changes would inevitably be required. 

	However, as more packages buy in into this scheme, and sa the
 scheme matures, the installed base would require that the interfaces
 and inner worlings of the emacsen common package not be changed at
 will. Indeed, the mechanism would have become de facto policy. 

	In order to reduce friction as the project grows, I think it
 is important that we actually codify these de facto policies, and
 bring them under the umbrella of a reasoned change mechanism, which
 the policy mailing list is expected to provide (more so than
 individuals, I think).

	I hope this explains my point of view better.

 I am a friend of the working man, and I would rather be his friend
 than be one. Clarence Darrow
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: