Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
Hi,
>>"Santiago" == Santiago Vila <sanvila@unex.es> writes:
Santiago> On 10 Aug 1999, Manoj Srivastava wrote:
>> Hi,
>> >>"Santiago" == Santiago Vila <sanvila@unex.es> writes:
>>
Santiago> If we followed this rule of "only object in extreme circumstances",
Santiago> we could be drawing circles forever. See:
>>
>> On the contrary, if every one objected formally all the time
>> we shall never resolve anything.
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.
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.
Not mentioning symlinks in no way prohibits them
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.
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.
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.
>> 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.
Requiring us to please all the people on the list all the time
would make it impossible to achieve anything in here.
Santiago> This issue, however, seems not to be very technical but
Santiago> quite subjective. I wonder if the *technical* commitee has
Santiago> really something to say about this.
Ask them. Yo have the right, after all.
manoj
--
Proposed Additions to the PDP-11 Instruction Set: BBW Branch Both
Ways BEW Branch Either Way BBBF Branch on Bit Bucket Full BH Branch
and Hang BMR Branch Multiple Registers BOB Branch On Bug BPO Branch
on Power Off BST Backspace and Stretch Tape CDS Condense and Destroy
System CLBR Clobber Register CLBRI Clobber Register Immediately CM
Circulate Memory CMFRM Come From -- essential for truly structured
programming CPPR Crumple Printer Paper and Rip CRN Convert to Roman
Numerals
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: