Re: /usr/doc transition and other things
I've been gone a week; this mail is a kind of summary reply, where I
pull together a number of threads.
Raul Miller wrote:
> On Sat, Aug 28, 1999 at 12:50:57PM +0200, Richard Braakman wrote:
> > That would be awful. Having to wait while something is rubberstamped,
> > just to get around an issue of protocol -- that just adds a useless
> > layer to something that is already ponderous. This is a volunteer
> > project, not a phone company!
>
> [1] Please read the constitution. It has some very specific things to
> say on this subject, and re-reading it would probably save us all a
> long email discussion.
I did. The Constitution has nothing to say about the policy manual or
the group that maintains it. That entire issue was deliberately left
out of it.
I still stand by my earlier position:
> > No, the debian-policy list is responsible for the Policy Manual, and
> > maintains it to the best of its collective ability. The result is
> > good enough for the Debian Project to adopt as its policy for package
> > maintenance. As long as that state of affairs continues, we're doing
> > it right.
The Technical Committee need not be involved unless there is a
disagreement; for example, if the Policy Manual decrees something
that a package maintainer does not wish to implement. That happened
with the /usr/doc -> /usr/share/doc change, for example.
The mere filing of a bugreport ("declaring packages buggy") does not
indicate disagreement; the maintainer of the package in question may
well agree that its noncompliance is a bug.
I disagree completely with the position you took in
<[🔎] 19990829120927.A909@usatoday.com>:
> Technical policy is supposed to be ratified by the technical committee.
> [The committee hadn't been doing its job, but that doesn't free any of
> us from the responsibility for failures in technical policy.]
The Technical Committee has no business ratifying anything. According to
6.3(5) of the Constitution:
5. Technical Committee makes decisions only as last resort.
The Technical Committee does not make a technical decision until
efforts to resolve it via consensus have been tried and failed,
unless it has been asked to make a decision by the person or body
who would normally be responsible for it.
The Constitution simply does not state how technical policy is set in
the first place, but the section about the Technical Committee strongly
implies that this is done by consensus.
> (*) The developers as a whole can set non-technical policy without
> recourse to the technical committee. Consensus is not needed here,
> just a successful vote.
Non-technical policy is not my concern here. Most of that has
been moved to the Developers Reference.
> (*) Policy is *supposed* to be a formulation of existing practice.
> If everybody agrees, the technical committee doesn't need to get
> involved.
No, existing practice is not necessary. Policy merely needs to be
agreed on.
> The technical committee only needs to be involved where, for example,
> the policy group wants to implement a policy which differs from what
> a package maintainer has agreed to.
Can you explain that last sentence further? In what way does a
package maintainer agree to a policy?
> As you say, this is a volunteer effort. [And, to paraphrase Linus:
> standards based on existing practice tend to be good, while standards
> based instead on fiat tend to be bad.]
Standards based solely on existing practice also tend to be bad; their
main function is to codify existing bugs. The best standards are
developed by extending and unifying existing practice.
Richard Braakman
Reply to: