Re: /usr/doc transition and other things
On Mon, Aug 30, 1999 at 07:26:47PM +0200, Richard Braakman wrote:
> I've been gone a week; this mail is a kind of summary reply, where I
> pull together a number of threads.
Often, those are the best kinds of replies.
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!
Raul Miller wrote:
> > [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.
On Mon, Aug 30, 1999 at 07:26:47PM +0200, Richard Braakman wrote:
> 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.
Er.. you're suggesting that the policy group has powers beyond what's
granted by the constitution?
The constitution talks about the powers of developers as a individuals,
and as a group:
The maintainers of the debian-policy package have the powers, etc.
as described in section 3 of the constitution. Where policy impacts
other packages, you need to revert to the consensus process outlined
in section 4 of the constitution -- except for technical policy changes.
When Ian drafted the constitution, he felt that the consensus process
would be inadequate for technical issues, so he specified a technical
committee for that purpose (section 6 of the constitution).
> 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.
Basically, yes. But, wishes are intangible... That there are something
like 2000 packages out there which haven't implemented /usr/share/doc/
should have been sufficient clue.
> 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:
I was using the term "ratify" as shorthand for "consider a well thought
out proposal submitted to the technical committee and approving it."
> 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.
Basically, I'm not sure what your point here is.
> > (*) 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.
I'm not sure what you're saying here.
> > 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?
By implementing the relevant aspects of it.
[Technical policy usually specifies some sort of interface -- where a
package implements that interface the package maintainer is agreeing
with that 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.
I have no disagreement with this, as a general statement.
--
Raul
Reply to: