Re: ideas underlying policy
>> This is the second draft of this document <<
I think I've waited long enough for comments on the points where I asked
questions. Which is to say: I'm winging it.
I've incorporated, to some degree, comments from Manoj Srivastav, Buddah
Buck, J. Ray Dassen (?), and Dale Scheetz. I've also spent a little time
reviewing documentation in doc-debian.
If there are no substantial comments on this for a while, it'll
probably be time to go over it again to clean up issues of grammar
and voice.
Aside: I'm a little disappointed that the Verisim search on
www.debian.org didn't yield any copies of the debian manifesto. I'd
think that we'd want to have the contents of doc-debian generally
available.
--
Raul
What is Debian's Policy, and Why Should I Care?
Long before Debian was formed, there were a variety of Linux
distributions. The people putting together those distributions did a
pretty good job, but they were all put together by an individual or a
small group, which was frustrating for people who wanted to improve the
distribution.
Debian was formed to take advantage of the strengths of the Linux
community, and put together an "open" distribution. Where, at least in
principal, anyone could chip in and make things better. See "The
Debian Manifesto" for more details. [If anyone has any earlier
historical documents to reference, please speak up.]
So, we came up with an idea of a distribution that was designed to allow
people to contribute: one where you could upgrade the system smoothly,
without having to reinstall everything, one where many people would work
together to make the distribution.
For this to work, we need to focus on freely distributable software
(thus the Debian Free Software Guidelines). More than that, we've
formulated policy: a set of standards and rationales that lets packages
put together by people who have never even met work smoothly in a
variety of environments and configurations.
This policy reflects a lot of work by the authors of the document, and
others. The policy is a rough outline of how Debian is supposed to work,
as a system.
It's critical that we have a standard to work against, otherwise we
wouldn't be able to get our packages to interoperate. It's also critical
that we understand the reasons behind the standard, so that we can solve
the usual standardization problems (conflicting standards, no applicable
standard, conflict between standard practice and standard-as-written,
and lengthy standard release cycles).
Ideally, we would like people to be able to use their experiences on
other (similar) systems, without having to do a lot of study. Ideally,
we would like packages from several years ago to work smoothly in a
system together with packages we're writing now, and packages which will
be written several years from now.
In practice, it's not always so simple. Where we have to make
compromises, we tend to favor widely adopted standards, and we try to
err on the side of system stability. Keeping an eye on the future, we
probably ought to err on the side of simplicity.
Many issues have several equally valid technical solutions, but a
coherent distribution has to make a decision between competeing
solutions -- conventions (like the location of the http server document
root) that help different packages in the distribution cooperate and
depend on each other. Debian's policy documents are also a compendia of
such conventions critical for a cohesive OS.
Debian's Policy Manual is a work in progress, describing where we think
we are, and where we think we want to be. It's important to read through
the manual, if you're putting together a software package. Even if
you're not putting together a package, understanding the manual will
clear up a lot of little questions you might have about how things are
laid out, and why.
Debian's distribution itself is a work in progress. At the time of this
writing, we have a lot to do before system administration really makes
sense. Ideally, a person should only have to enter relevant information
once (and when the configuration needs to be changed). Ideally, a person
shouldn't have to study a lot of documentation for a long time before
they go about changing something which they have a basic understanding
of.
In practice, we sometimes ask the same questions multiple times (when
upgrading packages, or when putting the same configuration on many
systems), and we sometimes don't meet our goal of having packages "just
work" without requiring any configuration.
Ideally, there should be a simple way to tell someone how to find
documentation on an issue they're interested in. In practice, we're
still working on that... One advantage of following standards is that we
can take advantage of existing documentation.
Furthermore, there's a world outside of Debian, and a lot of development
happens which is focussed on other distributions. In an ideal world,
it would be simple to incorporate much of work into Debian. We don't
want to sacrifice too many of our gains to make this happen, but it's
something to think about.
And, of course, as we incorporate new pieces of software, we sometimes
encounter situations which had never been encountered before, or
problems we thought we could avoid.
The policy manual has not been thrown together trivially, it has been
the concerted effort of a number of people, who may well have spent
weeks discussion on each little point. Policy is the distilled wisdom
and experience of a number of people who have worked together to create
the policy documents, and is meant to be something that one may depend
on to have been thought through, for the most part.
It's important to understand policy when putting together a package.
If you find yourself having to do something which seems to conflict
with policy -- where it seems like you should do things differently,
please take a moment and reflect on the issue. If you take another
look at the policy you might see that there is some provision for the
underlying issue you're trying to address. If after careful review you
still think policy is flawed in some way, then please include a comment
to that effect in your package's change log, and please file a bug
report against policy. You probably also want to leave a comment in the
changelog when you agree with the approach recommended by policy.
If you have experience in writing portable software, in adminstering
large systems, or if you just have time to help resolve some of our
issues, you might try your hand at solving some of our long-term goals.
Development requires talented individuals, and an elegant solution
benefits us all. [Please be careful, though: these problems are a bit
subtle.]
Ultimately, we're trying for a distribution that makes sense. Policy is
a step in that direction.
------------------------------------------------------------------------
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: