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
view.
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
upon.
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.
manoj
--
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: