Re: /usr/doc transition and other things

[Manoj Srivastava <srivasta@debian.org>]

Hi,
>>"Raul" == Raul Miller <raul@usatoday.com> writes:

 Raul> And maybe I don't.  Perhaps you have a specific example in mind?

        I am still trying to clarify what would be the accepted means
 of changing the policy from initially saying one thing (/usr/doc) and
 then, at a later date, saying something quite different
 (/usr/share/doc). 

 Raul> That said:

 Raul> First off, I'm not sure it's a good idea for policy to be a rapidly
 Raul> changing entity.  Debian produces packages -- policy is a means to
 Raul> that end.  Having a fairly stable policy might not be very exciting.
 Raul> But a stable policy is easier for people to learn, use, and document
 Raul> than a changing policy.  At least, to the degree that policy specifies
 Raul> interfaces [and where it doesn't specify interfaces it's probably not
 Raul> technical policy].

        Looking at the past history of the package, since april 1998,
 there have been 5 content changes. That is about one change per
 quarter, I don't think we have to fear much about rapidly changing
 policy documents.

        I am merely confused about _how_ policy can be changed at all
 -- after all, this mailing list ahs no constituional authority to do
 so. I am also unclear about the make no policy that creates bugs in
 packages issue (which is related to policy only codifies existing
 practice statement).

        Suppose policy statres all packages must do AA. We decide that
 in the long run, all packlages must do, instead, BB. 

    1) The policy should not just be changed to say BB instead of AA,
       since that would make all previously conformant packages buggy.
    2) Policy should be amended to say that though AA is legal, it is
       now deprecated, and soon one would need to move to BB, and
       mention any actions that need to be taken during this
       transitional period (like symlinks, notices in READMEs, et al)

        Hmm. OK, I guess this means that the policy must transition,
 and not change abruptly. I can see advantages of this: since old
 packages are still conformant to a transitional policy, we need not
 be afraid of mass bug reports. 

        If we do adopt this methodology, then we can always say that
 any violation of policy can be cause for a normal bug report (under
 the old method, we would ask that mass reports not be filed, but that
 is messy, cause people may not read or remember reading the
 exhortation not to file reports)

        However, I think this would increase the transition period. If
 it makes the transition smoother, a slower transition may well be
 worth it. 

        Also, one would need a strategy document, which shows how
 policy should be changed in the future, in case more has to be done
 than make the now deprecated AA method illegal. 


     3) Once a reasonable number (to be decided, reasonable could also
        be nearly all) have moved away from the legal but deprecated
        old AA method to the new BB method, policy can be changed to
        say BB is legal.

        Firstly, a point of clarification: policy _has_ to be changed,
 or else, over time, it shall be full of loopholes and anachronisms
 about legal but depreecated defunct ways of doing thisngs. Unless
 policy is changed, the project as a whole can never transition. 

        So, either we wait for all the packages to change (which can
 take a whilke, the tail of the bell curve can extend quite far), or
 policy has to be changed which still makes some packages buggy.

        Is this a fair representation of how things should be done?

 Raul> Fundamentally, it's far more important that technical policy always be
 Raul> correct than that policy be able to mutate rapidly.

        This is a truism, but I fail to see its relevance here. Slow
 changes are not synonymous with correct changes. 

 Raul> Finally, don't forget about the traditional practice of
 Raul> labeling something as "depreciated but legal".  You've not
 Raul> raised that issue in this message, but I think you touched on
 Raul> it in some other messages.

        I see. Is the above a reasonable facsimile of what you are
 talking about?

        manoj
-- 
 Command, n.: Statement presented by a human and accepted by a
 computer in such a manner as to make the human feel as if he is in
 control.
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