Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
On 15 Aug 1999, Manoj Srivastava wrote:
> >>"Santiago" == Santiago Vila <sanvila@unex.es> writes:
>
> Santiago> This has not happened in this case. We decided to switch
> Santiago> from FSSTND to FHS, which includes switching from /usr/doc
> Santiago> to /usr/share/doc, and nobody objected, so we had a
> Santiago> consensus.
>
> We made a general, sweeping, policy decision, to adopt the
> FHS. The detail, it was expected, would be worked out. We also said
> that not all details of the FHS may be adopted (/var/state is one
> that comes to mind).
>
> We are now working the details out.
Well, you say that we made a "general" policy decision to adopt the FHS,
but the fact is that policy was patched to read /usr/share/doc everywhere
instead of /usr/doc. This does not seem like a little "detail" to me.
> Santiago> This issue is already resolved by current policy, which
> Santiago> says to use /usr/share/doc, with no special symlinks or
> Santiago> anything.
>
> No. The policy says no such thing. Show me, the paragraph,
> where it says that.
About /usr/share/doc: There are lots of paragraphs talking about
/usr/share/doc, I don't think we need to quote them.
About symlinks: see below.
> Not mentioning symlinks in no way prohibits them
You may be mixing different things here.
I thought we were discussing about this proposal (the one in bug #42477,
i.e. /usr/doc vs /usr/share/doc).
You seem to be talking about "/usr/share/doc with symlinks" vs
"/usr/share/doc without symlinks".
> Santiago> I don't have any special "model of doing things". I just
> Santiago> think that we reached a consensus when we decided to switch
> Santiago> from /usr/doc to /usr/share/doc.
>
> We are not rescinding that.
I think we are.
> Santiago> Now some people want to break the consensus and go back to
> Santiago> /usr/doc, and I consider this as a bad thing, because it
> Santiago> breaks a previous consensus. That's all.
>
> I think you are mistaken. The people merely want to defer the
> timetable for that particular move. The original decision to adopt
> the FHS did not do anymore than set a tentative timetable, and the
> timing details can be defined by subsequent proposals, like this
> one.
I thought that policy was policy, not "tentative" policy.
The way I read your words it almost seems that someone has to present a
proposal and get seconds to keep things as they are (i.e. use
/usr/share/doc without requiring symlinks).
> Santiago> If you think current policy procedures are unacceptable,
> Santiago> please amend them. I don't think it is necessary.
>
> I think we do need to specify some additional guidelines for
> using the veto. Overfrequent (note: I did not say frivoulous) use of
> the veto shall shackle this group, since that would require near
> unanimity, rather than the 75% super majority we agreed to when we
> adopted the guidelines.
If we go back to /usr/doc, I will be tempted to use the word "frivolous"
for the previous policy amendment that switched from /usr/doc to
/usr/share/doc some weeks ago. I think policy matters should be treated
more seriously than that, and going back to /usr/doc would be a bad
precedent.
> >> I think that the current attitude of intellectual intolerance
> >> (I *must be right, and everyone else is obvioulsy wrong) would make
> >> the policy list ineffective.
>
> Santiago> The policy list is still effective for dealing with
> Santiago> technical issues, and I hope it will continue to be.
>
> I think we can be more than that. I think that we should be
> able to pass amendments that may even be unpalatable to some people.
For example, the symlink forrest on a per package basis? ;-)
> Requiring us to please all the people on the list all the time
> would make it impossible to achieve anything in here.
I wish you were a little bit more optimistic.
I think the procedure for amending policy (proposed by you, btw :-) has
worked very well so far, and I'm very glad of that.
"impossible to achieve anything"? The reality I see is very different.
Thanks.
--
"75ec58b08ad1131a4cb235931704baa5" (a truly random sig)
Reply to: