RFC: Debian-Architecture document

[Jonathan Walther]

Request For Comments, please.  I know, theres typos and grammatical errors.
I was very tired when I wrote it.  They'll be fixed later.  Thoughts on the
content?  Did I miss anything?  Get anything wrong?

-------------------------------------------------------------
Debian is a *big* system.  How do 500 developers, all largely equal, manage
to cooperate and coordinate this without imploding?  By arranging
themselves, not on hierarchical lines, but in a strong fabric.

In this document I hope to illuminate the various subsystems which form the
woof and weft of our project.

Simplest to document, is the average maintainer.  He is responsible for one
or two, maybe a few more packages which, once packaged, require little effort
to maintain.  Maintaining can sometimes involve developement, because some
software needs source modification before it follows our policy.  Some
packages require EXTENSIVE modification to do this.  But the average
maintainer can pretty much stick to himself, and usually does, except where
he needs to coordinate with another developer.

What all developers have in common:
  We all have an account on master
  We all can subscribe to -private
  We all have one vote in SPI, and in the Debian project itself
  We can all influence the projects policy
  We all have certain fundamental outlooks in common, due to excellent
    screening by James Troup and Martin Schulze over the years.  This
    more than anything else I think, has let us keep on an even keel.

The things we have in common, unite us.  But what prevents some socially
skilled demagogue from rising to power in Debian, and imposing a
dictatorship?  Or an oligarchy?  Our distributed nature and very numbers
makes such an undertaking hard.  So does the
fact that we are a volunteer organization, so members largely don't have
time for such politicking, only developement.

But we have several core teams running as a woof across the weft of the
ordinary developer, and each other, that makes any takeover attempt futile.
These are "enclaves of power", where one or two developers already has a
dictatorship, and the other members follow their lead.  The enclaves
balance each other out quite nicely, while ensuring that some major tasks
get done.

The teams are developers whose packages have enough in common that they
have to coordinate frequently with each other.  These are the "enclaves"
I've run across.  There are probably more.  These are the ones I know about. 

base
  Any maintainer of a Required package is in this one.  They have to coordinate
  very closely or the system would be fundamentally unusable.
X
  The GUI subsystem is fairly important to us.  Branden Robinson and team have
  been doing a great job.  I hope Xfree is taking their patches into account
web/documentation
  Also doing a good job.  Has root on our webservers and the power to add
  to our official documentation or not.
policy
  We all have the right to participate in policy making decisions, but only
  a few have the power to declare, "it is so", and stick "it" in our official 
  Policy document, whether it be unilaterally or upon concensus.
release
  Manages the release process.  Making of cdrom iso images, making 
  announcements, making sure freezes are respected.
new-maint
  Handles the swearing in of new maintainers.  I hope our replacements for
  James  and Martin are half as good as their predesessors
support
  All of us who answer questions on or operate the mailing lists and irc 
  channels, etc.  This almost isn't a proper enclave.  I think mainly of the irc
  support channel #debian on irc.debian.org, and those who operate that
  irc network and that channel and related channels.
infrastructure
  Those who run our web servers, ftp servers, and administer our email and
  mailing lists, set up our archives and so forth.  our sysadmins.  lets hear
  it for them, they do a thankless job, without which we wouldn't have anything
packaging software
  Those who work on our package management software.  Its central to the whole
  Debian distribution.  In a limited way, that software sets our policy.
install procedures
  Our boot floppies, our install floppies, our install software.

There is only one minor flaw, and this stops us from innovating at the same
pace we did in the beginning.  We have an elected leadership, true; but
even before the constitution of Debian was ratified, it was noted publicly
that the sole purpose of elections and positions and such was to distract
the politically minded troublemakers from becoming too much of a nuisance
to real developers.  They could go bug he who was elected "most popular".
But thats not the problem.  The problem is, with all this "horizontal"
organization, we lack "system architects" for the project, who can set
innovative goals for each new release, so we can keep the edge we once had.
Red Hat has not yet, but is almost caught up with us.

In the beginning, Ian (Taylor?) was the head architect.  Since he left,
architecturally, we've really been coasting.  We have made a few obvious,
sensible decisions, such as switching over to shadow passwords, using pam
authentication wherever possible, making the X windows root menu structure
standard across window managers.  We've made a few innovations, such as our
"up-date alternatives" mechanism.  I don't even need to mention apt-get.
Its the bomb.  Making "info" userfriendly, (PageUp and PageDown do the
Right Things these days...), putting in a default manpage so programs
without them show you how to get one added, our uniform keyboard policy.

Maybe we just don't need to innovate as much these days:  the cool things
have been done.  I don't think so though.  How are we to get people to
think at the System Architect level, and not at their "team" level, or even
just their package level?  A lot of good developement is happening.  We are
busy refining our distribution.

We've refined for long enough.  Isn't it time to release our last 2.x
release, and figure out what bold, cool things we are going to throw in the 
pie for 3.0?  What cool things can we do that are noticeable to users, to
make them say, "wow, cool!" all over again?  Hell, never mind users.
Something that will make US say to ourselves, "wow, cool!".  Something that
will involve all of our cooperation but not too much effort?  I'd like to
hear your thoughts.

Jonathan