Process is no substitute for understanding
Steve Gore writes ("Re: New policy draft available at http://master.debian.org/%7Esrivasta/policy/";):
> Form a group (Policy Advocacy Team?) to pick up new policy
> proposals, [...] I know that the first big hurdle would be "What if
> someone gets assigned to a proposal they don't agree with?", [...]
I think this demonstrates clearly an approach which I think is also
shared to some extent by Manoj and some others on this list: that the
problems with policy can be fixed by adding process.
I think that the fundamental problem is that the policy manual needs
to be coherent and well-thought-out, which means that it needs to be
edited by one or more people who are technically excellent, have the
foresight to anticipate problems, and who are not afraid to put their
own opinions into practice (after discussion, of course).
We must not continue to maintain the policy manual in a way that means
that (a) decisions are be made based on the support of any few of our
(400-odd?) developers - not all of whom are equally technically
excellent - if insufficient people happen to be around at the time to
object; and (b) straightforward and correct decisions are stalled
because either someone who is not altogether clueful in the area in
question doesn't understand it and objects, or because the work item
`fell through the cracks' and didn't attract enough `me too's.
As a couple of examples, the bug I reopened at the start of this
flamewar falls into the category (b), and the decision to change the
reference to the FSSTND to a reference to the FHS, without writing a
transition plan, is a case of (a).
That latter decision has cost most people in the project some time, in
some cases a considerable amount of time, and has (by sucking effort
into firefighting that problem instead of doing useful work) probably
done significant technical damage to the project beyond what is
visible (software sometimes not finding info files or manpages, etc).
We must take control over our key technical standards away from a
mailing list and give it back to technical experts !
As a related issue, I think that we must cease to make the false
dichotomy between `policy' and `manual for core software'. When I
first wrote the policy and dpkg manuals, the distinction was made for
the benefit of anyone who wanted to use dpkg for some other purpose:
the dpkg programmers' manual described the behaviour of dpkg and what
you must do to make things work, whereas the policy manual documented
decisions - either essentially arbitrary or requiring discussion about
the right way forward - about the ways that different parts of the
system interact.
I think that (for example) the maintainer of dpkg should have the
complete authority to write the dpkg programmers' manual, and that
packages should conform to the requirements of that manual.
Maintainers of packages which by their position effectively set
standards for other packages should not have to come here and engage
in a complex and bureaucratic process in order to document the
behaviour of their software !
The bug I reopened at the start of this argument is a case of this,
too.
Ian.
Reply to: