Re: what needs to be policy?
Hi,
[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.
manoj
--
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: