Manoj Srivastava writes ("Re: Bug#30036: debian-policy could include emacs
policy"):
...
> Straw man. No one has said anything about dictating how
> programs work. All that has been proposed is standardization of
> interfaces between programs that has been left to the whims and
> fancies of random development.
The `whims and fancies of random development' - ie, the decisions of
the relevant maintainer, as informed by whatever discussions etc they
feel are appropriate - have always been how new design of interfaces
has been done in the Debian project.
Design by committee - which is what you seem to be proposing to
replace it - is not a good replacement for the decisions of the people
who are writing and maintaining the code, and the usual mechanisms for
influencing them.
Leaving aside arguments about the merits of having all of Debian's key
interfaces designed using the policy amendment procedure, there is
another argument I can use:
Suppose the menu maintainer wants to make a change to an interface
they've defined, of which the policy group claim to have taken
control. Now suppose that they go ahead and release new code,
together with the corresponding documentation.
By what authority do the policy group say that they shouldn't do
this ?
The constitution says that developers may:
3.1(1) make any technical or nontechnical decision with regard to
their own work;
The technical committee could perhaps override their technical
decision, since the documentation which describes the menu system
might well count as technical policy. So, the policy group would have
to ask the technical committee to overrule the developer - but they'd
have to make a case on the issues, not just that the developer wasn't
following a procedure that the policy group have made up for the
development of their own work.
It's one thing for the volunteers who have agreed to maintain the
policy manuals to decide to give themselves what they see as a purely
administrative role by adopting the policy procedure; it's quite
something else for them to insist that other developers need to adopt
this procedure too !
Ian.
