Re: 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.
While I think it is good as far as it goes, I think it is missing
There is in my opinion a difference between goals (such as "Debian
should be a complete distribution") and a standard to implement that
goal (such as "No package in main can depend upon a package outside of
main", or "Packages MUST NOT depend on packages with a lower priority
(base, standard, optional, extra) than themselves").
Reading your draft, I see discussion of the importance of the goals,
but not the importance of the standards -- or at least, not in as many
You mention "guidelines" instead of "standards". To me, there is a
major connotative difference between those two words. To me, standards
are not to be broken. They are, in a way, a promise between
developers, and developers and the user, that the goals will be met.
"Guidelines" seem much less enforced. "Advisary" rather than
"promisary". In addition, "standards" are the traditional way for
disparate groups to work together -- I know that the standard 2x4 I buy
at any American lumberyard will be the same size (1.5"x.75"), etc.
> 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
> 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.
I would state "a set of standards that...". Or even better, "a set of
goals and standards that...".
> 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
> 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 email@example.com
> with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
Buddha Buck email@example.com
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com