Hi,
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
