Debian Weekly News - email

Subject: Re: Process is no substitute for understanding
From: Manoj Srivastava <>
Date: 24 Mar 2000 09:47:03 -0600

>>"Ian" == Ian Jackson <> 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 think 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 concentrates 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 cannot 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 personnel 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
 this work.

        Not there are no problems in the current approach -- we do
 need a chairman(chairpeople?) to address some of the issues that Ian
 has raised:

        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
           interest alive.
        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 maintain 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 compatibility with the rest of Linux
 community. Retaining compatibility is vital to the viability of

        The assumptions were that the
 a) The symbolic link issue should not be an insurmountable problem
    for developers
 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 directly look into the doc directory
 e) people who maintain 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. Neither should the
 implementation of the package manager.

        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 competence 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 have 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 maintainers of those packages 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
 from it.

 History tends to exaggerate. Col. Green, "The Savage Curtain",
 stardate 5906.4
Manoj Srivastava   <>  <>
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

To: Ian Jackson <>,
  Wichert Akkerman <>
Subject: Discussion on IRC about policy
From: Manoj Srivastava <>
Date: 27 Mar 2000 15:08:04 -0600


        Wichert suggested a meeting on IRC, for discussion about
 -policy. The discussion is open to all comers (, but
 may be moderated and read only, on a channel to be decided.

        Since Wednesday appears to be the earliest time that may work,
 how about this:

 Wednesday March 29th
        18:00 CET
        16:00 GMT
        10:00 CDT

        I must confess I am not sanguine about this. The positions and
 arguments have been articulated on the mailing list. An irc meet is
 useful if there is any ambiguity. or possibility of convergence of
 views. I'm always willing to listen, and participate in a discussion,
 but I feel that the positions in -policy are far enough apart, and
 deeply enough entrenched, to mitigate much chance of convergence
 through an informal chat.

        I'm willing to be pleasantly surprised.

 Better hope the life-inspector doesn't come around while you have
 your life in such a mess.
Manoj Srivastava   <>  <>
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

To receive this newsletter weekly in your mailbox, subscribe to the debian-news mailing list.

Back issues of this newsletter are available.

This issue of Debian Weekly News was edited by Joey Hess.