Re: /usr/doc transition and other things
Manoj Srivastava <srivasta@debian.org> writes:
> 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)
Here's where the "Strategy" document I once suggested could come in.
Strategy could say, "we want to change to BB, however doing so all at
once would cause problems, therefore, as a first step, Policy will be
changed to say, 'blah...'. Once we have reached <some intermediate
goal>, then Policy will be changed to say, 'yackka....'." Etc.
This would help make it clear, both internally and externally, exactly
what we're doing, and *why* Policy currently mandates something that
seems to be an intermediate state between AA and BB (for example).
[...]
> 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.
Hmm, I didn't notice this paragraph when I started the reply. Ok, I
guess I'm *not* shouting into a void. :-)
> 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.
Absolutely.
> 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.
The former doesn't work in many cases. If the goal is to get to BB,
but BB violates existing policy, then we'd have to wait till there
were sufficient packages that violate policy (but meet our future
goals) in order to change policy. Which doesn't seem like a very
clean way to do things -- we'd end up actively *encouraging* people to
violate policy.
So, really it comes down to: we have to create intermediate policies
somehow (preferably with a Strategy document to explain to the world
what we're trying to do), or we have to declare existing packages
buggy once in a while.
The tricky bit is that it's going to be much more difficult to propose
a confusing, multi-step strategy than to propose a simple change in
policy. E.g. it was easy to propose "Switch to FHS", and people
bought into it. Proposing something that didn't cause transition
problems would have been quite a bit more difficult. (As evidenced by
the problems we've had coming up with a transition strategy that
people will buy into.)
Nevertheless, I think it's a worthwhile goal to start trying to do
this, somehow.
--
Chris Waters xtifr@dsp.net | I have a truly elegant proof of the
or xtifr@debian.org | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Reply to: