ideas underlying policy
>>This is a draft.<<
I've written a document which touches on what I feel are important
meta-policy issues. It's a little bit of history, a little bit of
speculation, and a bit of an essay on how I think of debian.
I'm sure other people have different ideas. I hope none of what
I've written makes anyone angry or annoyed.
If you feel you could write this better, you're probably right.
Please do so.
If you think I've misstated some point, please respond to this
message with a reasonably lucid explanation.
--
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.
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 guidelines 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.
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 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.
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.
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 include a comment to that effect in your package's change log,
and please file a bug report against policy. [insert more detail here.]
Also, 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: