Re: Process is no substitute for understanding
>>"Ian" == Ian Jackson <email@example.com> writes:
Ian> I think that the fundamental problem is that the policy manual needs
Ian> to be coherent and well-thought-out, which means that it needs to be
Ian> edited by one or more people who are technically excellent, have the
Ian> foresight to anticipate problems, and who are not afraid to put their
Ian> own opinions into practice (after discussion, of course).
Personally, I don't thik that this is the only way that things
need be done. I find most Standards are in fact not created by a few
heroic figures; IETF, IEEE, and ISO working groups are not lone
``technically expert'' cowboys. If our policy matches the quality of
the documents produced by those bodies, I shall be content.
Indeed, this paragraph above demonstrates the flaws in the
position that Ian holds: It cncentrates power into very few hands,
and even though the power is not absolute, we all know how the last
policy czar position ended.
Secondly, this does not take into account the nature of the
project: This is a project run by volunteers, and the demands of the
real life job come first for most of us. Even Ian and I have not been
around consistently, we can not afford to have the whole project
dependent one any one person.
What Ian denigrates as process and bureaucracy, is merely a
mechanism put in place to ensure that no person is named to be in
charge of policy all the time -- and that personeell can come in and
go away at will.
Ian> We must not continue to maintain the policy manual in a way that
Ian> means that (a) decisions are be made based on the support of any
Ian> few of our (400-odd?) developers - not all of whom are equally
Ian> technically excellent - if insufficient people happen to be
Ian> around at the time to object; and (b) straightforward and
Ian> correct decisions are stalled because either someone who is not
Ian> altogether clueful in the area in question doesn't understand it
Ian> and objects, or because the work item `fell through the cracks'
Ian> and didn't attract enough `me too's.
Yes. The current policy process is hard to stomach for someone
who believes in the fundamental correctness of elitism. (I mean no
offence by that). The current policy process assumes that there the
developers on -policy do have the minimal competence required, or
that there are enough technically competent people on -policy to make
Not there are no problems in the current approach -- we do
need a chairman(chairpeople?) to address some of the issues that Ian
a) Have delegated power from the Project leader to over ride
the ``clueless'' objections
b) Move stalled discussions along by breaking deadlocks,
c) create a periodic report of the state of the policy to keep
d) Sweep through the so called unsexy proposals.
Ian> As a couple of examples, the bug I reopened at the start of this
Ian> flamewar falls into the category (b), and the decision to change the
Ian> reference to the FSSTND to a reference to the FHS, without writing a
Ian> transition plan, is a case of (a).
Seems to me that most technically excellent people weren't
paying attention for (a), and thus making any one of the technically
excellent people a policy editor is fraught to failure since you
can't force a volunteer to work, or perhaps (a) was harder than first
Ian> That latter decision has cost most people in the project some
Ian> time, in some cases a considerable amount of time, and has (by
Ian> sucking effort into firefighting that problem instead of doing
Ian> useful work) probably done significant technical damage to the
Ian> project beyond what is visible (software sometimes not finding
Ian> info files or manpages, etc).
This is ironic, considering that most of the mess was created
since the people who maintian dpkg (whom you want to give absolute
power over determining policy) had been neglecting dpkg and the
simple solution was deemed impossible, since changes to dpkg seemed
to require a snow storm in hell at that point.
Unstable breaks. And the work put i by people would have been
required in any case to move to the FHS in any case -- and we need to
move to the FHS to retain compatibilty with the rest of Linux
community. Retaining compatibility is vital to the viability of
The assumptions werre that the
a) The symbolic link issue should not be an insurmountable problem
b) Once helper packages were modified, about 60% of the packages
should be conformant (assumption: helper package authors are
c) People not using helper packages should be cluefull enough to
manage a symlink on their own
d) not many programs direcly look into the doc directory
e) people who maintian programs that look into the doc directory were
competent to make them look into both places.
It seems that the last may not have been as accurate as
However, no amount of policy editor excellence would have
changed the latter, since we couldn't have hand held all packages
through the transition.
Ian> We must take control over our key technical standards away from a
Ian> mailing list and give it back to technical experts !
I find this kind of eliticism abhorent, and worse, unworkable
as the project scales up. We need to decentralize in order to grow,
not go back to a failed policy czar process.
Ian> As a related issue, I think that we must cease to make the false
Ian> dichotomy between `policy' and `manual for core software'. When
I don't think it is a false dichotomy. The implementation of a
C compiler does not decide the language. Nither sould the
implementation of the package manger.
You seem to have more faith in the people who program dpkg
than I have. And since dpkg programmers have changed, and, indeed,
there have been numerous NMU's to that package from a large variety
of people, I find your position cointradictory here.
Further, I have seen the dpkg code. I am underwhelmed by the
quality of that code, and that leads me to have even less confidence
in the actual technical copetence demonstrated therein. This is a
personal opinion, but relevant, I think, even tough it sounds
rude. If we were not talking about something I consider critical to
the project, I would not ahve brought this up, and I do apologize. I
know that is sounds ad hominem, but I am trying to really pass an
objective judgement here.
Ian> I think that (for example) the maintainer of dpkg should have the
Ian> complete authority to write the dpkg programmers' manual, and
That is fine. But the dpkg programmers' manual would not be
policy, and indeed, dpkg must conform to policy, not the other way
Ian> that packages should conform to the requirements of that manual.
Ian> Maintainers of packages which by their position effectively set
Ian> standards for other packages should not have to come here and engage
Ian> in a complex and bureaucratic process in order to document the
Ian> behaviour of their software !
This is wrong headed. The manitainers of those pacjages should
conform to policy, and they can't, or will not, then we should look
for a package that shall. The tyranny of monopolistic package
managers has stifled the project in the past, and we should get away
History tends to exaggerate. Col. Green, "The Savage Curtain",
Manoj Srivastava <firstname.lastname@example.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C