Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
Hi,
>>"Chris" == Chris Waters <xtifr@dsp.net> writes:
>> Secondly, I think that the policy should not hard code release
>> names
Chris> I would call this a serious flaw in policy then.
My opinion is a flaw in policy? ;-)
Chris> I think we NEED a way to say, "these are the rules for release
Chris> "X", these are the rules to follow subsequently." Ideally, I
Chris> think we'd have a strategy document that takes precedence over
Chris> policy, but that's a fairly major proposal, one that I'm a
Chris> long, *long* way from proposing formally. :-)
Think about adding a layer of abstraction. I would rather
couch your example above as "These are the rules that need be
follwed right now. (footnote: at a latter point policy may be
amended to follow these other rules"). That leaves us some leeway to
decide when to make the changes, and allows us to reflect upon and
change the ``other rules'' to reflect any changes in the situation.
It also does not tie us down to a particular release frame
(the project may decide to have an e,ergency woody release two
weeks after potato -- not very likely, but why close doors we need
not?)
Chris> The way this was handled in the symlink proposal (leaving the
Chris> cleanup to an unspecified future policy change which may or
Chris> may not ever happen) strikes me as a *really* awful way to
Chris> handle this. Far better to just allow the proposal to specify
Chris> which parts apply to which releases if it's important to do so
Chris> (as it is with these proposals).
I think the loss of flexibility is not worth the gains. Of
course, I may be missing some of the gains, since all you say is that
your opinion is that this is a really awful way, but give no
rationale (at best, the gain is that you feel better about the
proposal, but that is not really a satisfactory reason for me).
>> At a latter date, policy can be changed to reflect that the move is kosher.
Chris> I think this is much worse than "hard coding" release names in
Could you give some reasons?
Chris> policy. Though I agree that neither is *ideal*. But there's
Chris> only so much that can be done today. Either we institute
Chris> temporary policy with *no* markings and *assume*[1] that we'll
Chris> fix it later, or we clearly mark it as temporary policy when
Chris> we all know that it is temporary policy. I think the latter
Chris> is *far* preferable.
We can mark it as a temporary policy. We just leave the end of
the temporary period open, to allow us to set the time when we are
closer to the change, and to change what needs be done if the
circumstances change (dpkg may get revamped, for example).
manoj
--
Fortune Documents the Great Legal Decisions: We think that we may
take judicial notice of the fact that the term "bitch" may imply some
feeling of endearment when applied to a female of the canine species
but that it is seldom, if ever, so used when applied to a female of
the human race. Coming as it did, reasonably close on the heels of
two revolver shots directed at the person of whom it was probably
used, we think it carries every reasonable implication of ill-will
toward that person. Smith v. Moran, 193 N.E. 2d 466.
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: