[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Process is no substitute for understanding

>>"Ian" == Ian Jackson <ian@davenant.greenend.org.uk> 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
 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 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
    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 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
 from it.

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

Reply to: