[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:

 >> Secondly, looking at what policy covers, there is no
 >> such thing as an expert.

 Ian> You're assuming that I'm suggesting that a single individual (or small
 Ian> group) be responsible for the whole of policy.  But, I don't think
 Ian> that's the way it should work.  I think that different aspects of
 Ian> policy should be edited by different people (whether they are
 Ian> different documents or not, and how to organise this with eg CVS, etc.
 Ian> are organisational details that can be worked out).  Probably we will
 Ian> need someone, or a few people, to act as the editor for the many
 Ian> things that aren't specific to a subsystem, and to manage the
 Ian> delegation.

        Lets examine this proposition in some detail, and see how it
 stands up to a process of thinking it through.

        Let us examine the areas in which expertise is not quite
 common, and these areas may well see explosie growth in the next five
 years, and may require policy decisions (I'm not even touching the
 more esoteric areas like embedded Debian).
 1) Emacs policy
 2) X policy
 3) Java
 4) KDE/Gnome
 5) SGML (we may have sgml tools and docbook peple taking action here)
 6) XML (and yes, it does require a separarte section, despite the
    naive supposition that XML is merely a SGML subsaet (which it
    isn't, technically)
 7) Security
 8) LSB
 9) IPv6
10) IPSEC (umm, on the merits, I do think the expertise may be
    sufficiently different that security and IPv6 expoerts may not
    suffice here; depends on the experts in the other areas)
11) Clustering
12) boot floppies
13) Quality assurance
14) web team
15) package pool, ftp, and archive policy, as it may impact how
    packages are handled
16) autobuilders, make world process
17) HURD experts
18) Multimedia and convergence expets
19) ALPHA people
20) SPARC people
21) M68K people
22) IA64 people
23) Distributed and parrallel computing people
24) QoS people (this is a big one)
25) Debian for kids project

        And probably other whole areas I have missed.

        Now, we need to identify at least two experts in each area,
 and name them policy sub czars, or, shall w4e say, policy Dukes. And
 also a policy Baron for backup.

        The the DPL or the Czar has to keep tabs on all the people,
 making sure they are alert and responsive, and competent, and replace
 them as needed (man -- talk about bureaucracy). We already are at 48
 people -- and probably more named people, as ther areas come into our

        And if you have any ideas at all, and are not blueblooded
 enough to belong to this elite aristocracy, youhave to get the sign
 off from the porpah goldlet in the area your ideas happen to impinge

        Frankly, the day the DPL appoints 48 godlets to handle policy
 is when I leave policy to go to the dogs.

 Ian> For example, take the Emacs policy.  I don't know very much about how
 Ian> our Emacs installation system works, and if I were to be the
 Ian> maintainer of the general policy manual I would probably make mistakes
 Ian> if I just tried to decide things.

        Kinda goes against the grain for the whole tech committee
 idea, doesn't it? Five little men who know everything that is
 to be known avbout everything, and can pass solomon like judgemnt in
 all expediency on whatever question is posed to them? 

 Ian> I think we should abolish the project leadership because we should not
 Ian> hand over leadership to anyone who wants to exercise total power in
 Ian> the best interest[sic] of the project.

        One concession is enough, IMO.

 The use of COBOL cripples the mind; its teaching should, therefore,
 be regarded as a criminal offence. Edsger W. Dijkstra, SIGPLAN
 Notices, Volume 17, Number 5
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: