Re: Bug#30036: debian-policy could include emacs policy
Hi,
>>"Ian" == Ian Jackson <ian@chiark.greenend.org.uk> writes:
Ian> Joey Hess writes ("Bug#30036: debian-policy could include emacs policy"):
Ian> ...
>> I think we should move the menu hierarchy out of the menu documentation and
>> into policy. It is something that could benefit from being maintained by the
>> policy list, and it needs the weight of policy behind it to ensure that all
>> packages be made to comply with it, so that the menu hierarchy is kept
>> consistent.
Ian> Both you and Manoj have used the phrase `weight of policy'. Can you
Ian> explain what this means please ?
Here goes. When we make something policy, we are telling the
developers that these are procedures that need be followed. With the
growth in the number of developers, and packages, we are no longer a
close knit group that could follow all teh changes, and the
discussions, and which made possible rapid changes in interfaces
possible in a small group.
We now need procedures that would allow cooperation between a
large, and disparate, group of people, and we need stability. If the
interface is evolving rapidly, then developers are encouraged to go
off and develop the practice amidst a (small) group of cooperating
developers and packages; once the interface has solidified, then, and
only then, is it made policy, and conformance to it is a
requirement.
With the large number of packages that we have, there is
potential for a large number of issues that affect ones packages, and
it is contraproductive to have policy (mandatory practices, in a way)
change very often or whimsically. If it means that the freedom is
reduced so that we cooperate better, well, that comes with the
territory. Ones freedom is reduced whenever one has rules and
policies.
Ian> Debian's policy documents do not exist to give people a bigger hammer
Ian> to hit recalcitrant opponents over the head with.
Oh, for heavens sake. No, it is not a hammer. It is a
contract, more like, a contract that we ask developers to do things a
certain way, a contract that if thigs are done that way, we can
interact better, that there would be consistency, and that we shall
have a better distribvution than raw chaos and anarchy that would be
the alternative.
It is only reasonable (and polite) to be able to promise the
developers that when they do follow policy, any changes would be well
considered, and nothing would be rushed, that changes to policy shall
be discussed by a team of developers interested in policy, and
changes be made on consensus.
Ian> Our policy documents[1] exist to describe how things are done in
Ian> Debian, so that different maintainers can make software that works
Ian> together. Some of these documents are descriptions of essentially
Ian> political requirements, or of procedures; others are statements of
Ian> which choice Debian has made regarding various technical decisions;
Ian> still others are programmer documentation for our packaging tools,
Ian> utilities, etc.
Correct. And once we standardize on these things, I think we
should let things solidify -- I think we need that, in order to
transition from a small, close knit, group producing a niche
distribution, to a viable distribution of a rapidly mainstream
Linux.
manoj
--
Hard work never killed anybody, but why take a chance? Charlie
McCarthy
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: