[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: please vote...



Hi,
>>"Raul" == Raul Miller <moth@magenta.com> writes:

 Raul> Dale Scheetz <dwarf@polaris.net> wrote:

 >> The current "problem" has been caused by a recent policy decission that
 >> was malformed. "Thou shalt be FHS compliant" is not, and never should be
 >> considered, an adequate policy statement. I suggest that the policy group
 >> remove such statements, and replace them with "In order to become
 >> compliant with XXX, developers will need to impliment the following
 >> proceedures ..."

 Raul> This idea really appeals to me.  We might want to excercise our advice
 Raul> power and make a statement to this effect [once we have a chairman.]

        Objections:
        a) This would be a duplication of the material already in the
           FHS, where it is presented coherently, and has rationale,
           and all
        b) Details like this should not be in policy; it is already
           getting too large for a mandatory document, and it is
           accepted practice to have ancilliary documents that are
           referred to by policy. The FSSTND and FHS are one of
           those. 
        c) Most of the changes in the FHS do not require this anyway,
           things internal to a package, or where the changes are not
           suer visible due to flexibility in interface (info, for
           one) do not need a policy dictum. Only a user visible
           change like this warrants it, wehre the interface is just
           using ls or cat or a pager. 

 Raul> [Aside: Personally, I'd like to have seen /usr/doc -> /usr/share/doc/.
 Raul> and I'd have liked to see legacy systems left with /usr/share/doc ->
 Raul> /usr/doc/.  However, it's too late for that -- presumably, as you say,
 Raul> because policy didn't specify how FHS compliance should be achieved.]

        This is technically flawed, as it would break
 upgrade/downgrades, depending on the direction of the link. The
 lossage is dpkg removing documentation. There was an appendinx to the
 proposal that details the experiments conducted which demonstrate
 this. 

 Raul> I'll note that finding /usr/doc missing is far more likely to result in
 Raul> someone finding /usr/share/doc than finding /usr/doc/mesa-doc missing.

        Change dpk hnot to remove the files, and we shall all be
 grateful. But, in the meanwhile, this is a flawed proposal. 

 >> >From my point of view this is not a technical problem, but a political one
 >> within the policy group that can only be resolved there.

        You are wrong. The policy groups mandate is to make near
 concensual policy amendments. The only recourse for controversial
 techncial policy is this sommittee, or the vote by general
 resolution. Voting on technical issues is not recommended.

 Raul> While I agree about the cause of the problem, we're not being asked
 Raul> to solve the political aspects -- only the technical ones.  However,
 Raul> your arguments have swayed me -- if we had a ballot (which we don't),
 Raul> I'd probably be changing my vote to further discussion.

        I actually disagree about the problem (which does sound like
 blame shifting, actually). The problem is that there is not light
 weight process of making sontroversial changes to technical policy --
 and even the process that is open depends on votiong, wihch is a bad
 idea.

 Raul> The real issue, in my mind, is that if we don't implement some such policy
 Raul> we've measurably increased the amount of typing a person has to do to
 Raul> locate a package's docs (or copyright, etc.).  For some significant set of
 Raul> our user base, hours or days could be lost in finding docs [for example
 Raul> consider the case where someone has a script which greps /usr/info/,
 Raul> /usr/man/, and /usr/doc/ -- then consider analogous cases where there's
 Raul> no executable script but instead some sort of standard procedure.]

 Raul> I agree that Manoj's proposed solution is ugly, but even moreso
 Raul> is a situation where we have some docs in /usr/doc and others in
 Raul> /usr/share/doc/.  [In my opinion, of course.]

 Raul> I think I see what you're getting at, but I disagree on some of the 
 Raul> details.

 Raul> We do need a chairman, and a proper ballot on this issue, but Manoj's
 Raul> proposal was well formed.

        Thanks.

        Since we called for votes a long time ago, can we hear from
 the silent members of the ctte? Do we need new members (we are at the
 low end of acceptable strngth of the ctte, I think).

        manoj
-- 
 A Roman divorced from his wife, being highly blamed by his friends,
 who demanded, "Was she not chaste?  Was she not fair?  Was she not
 fruitful?" holding out his shoe, asked them whether it was not new
 and well made. Yet, added he, none of you can tell where it pinches
 me. Plutarch
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: