Re: Hard-coding release names in policy (was Re: [PROPOSED} delay the /usr/doc transition)
Hi,
>>"Chris" == Chris Waters <xtifr@dsp.net> writes:
Chris> Sorry, I'm not saying the latter is an inherently bad thing to
Chris> do, I'm saying that if that's our *only* option, then we may
Chris> have a problem. I *do* think it's bad to have "this may be
Chris> amended in the future" as our only way to embed strategy in
Chris> policy.
It is not the only way, but should only be used sparingly
(given the loss of flexibility that the fuzzy end state
provides). You have not convinced me that this is such a time.
Chris> Again, I think we need a way to describe our longer-term strategies
Chris> somewhere.
How formal do you want this to be? I would not make such
strategy documents static, nor a part of policy. What about a file in
the doc directory, to be removed when we are done? What about a fixed
bug in the bts?
Chris> Policy, IMO, should describe what to do now. But we *should*,
Chris> IMO, have somewhere that documents where we're trying to go,
Chris> and how we're planning to get there. That's why I think that
Chris> having a Strategy document that takes precedence over Policy
Chris> (i.e. can automatically obsolete parts of Policy and cause
Chris> them to be replaced when certain milestones are met) is a
Chris> great idea. (Although, obviously, a non-trivial project to
Chris> get started....)
I think this is too heavy wieght a process. I would rather
that the control be in the hands of a human, and not institute new
rules like that. The file I propose above would only serve to refresh
our memory, and so we do not run through all the old arguments again.
I think there is an advantage to not putting the policy list
in a strait jacket. If it makes sense now, it would still make sense
later. But leaving it informal gives us the option of changing if the
situation has changed. Making strategy that is fixed now is not as
good as creating guidleines that are hardened into policy when
needed.
Chris> You may be right that it's the best we can do at this point,
Chris> but then I think we should go all the way with this, and have
Chris> Policy specify the terms under which certain of its clauses
Chris> become obsolete, and what replaces them, rather than leaving
Chris> that up in the air. If we're not going to hard-code release
Chris> names, then we need to make sure we don't get stuck with a
Chris> temporary policy as permanent policy somehow.
Why do you have so little trust in the future policy decision
makers? I would seriously object to any body who tries to reach out
of the past and tell me that they knew back then the right thing to
do better than we do now, knowing the ground and the current
situation.
I would agree to keeping notes, and rationales, and what we
think should be done, and take the final decision later (which may be
to accept the old decision ``since nothing has changed''). Not
automatically.
manoj
--
Q: What do agnostic, insomniac dyslexics do at night? A: Stay awake
and wonder if there's a dog.
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: