Hard-coding release names in policy (was Re: [PROPOSED} delay the /usr/doc transition)
Manoj Srivastava <srivasta@debian.org> writes:
> 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.
Sorry, I'm not saying the latter is an inherently bad thing to do, I'm
saying that if that's our *only* option, then we may have a problem.
I *do* think it's bad to have "this may be amended in the future" as
our only way to embed strategy in policy.
Again, I think we need a way to describe our longer-term strategies
somewhere. Policy, IMO, should describe what to do now. But we
*should*, IMO, have somewhere that documents where we're trying to go,
and how we're planning to get there. That's why I think that having a
Strategy document that takes precedence over Policy (i.e. can
automatically obsolete parts of Policy and cause them to be replaced
when certain milestones are met) is a great idea. (Although,
obviously, a non-trivial project to get started....)
Policy could even *explicitly* defer to Strategy in such cases.
> 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?)
Ah, good point. But in such a case, if there *were* something in
Policy about Potato, then I think it would make more sense to release
a modified Potato in such an emergency, rather than releasing a
never-been-frozen Woody. For several reasons -- embedded release
names in Policy would only be one more reason. But yes, I do see what
you're saying here.
> 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.
At this point, I now think that both approaches (embedding release
names, or simply ignoring our long term strategy, and pretending that
some temporary hack is hard-and-fast policy) are bad, and that we
really *really* need a long-term Strategy to guide us through these
types of transitions. Policy is not designed for that, and it's not
particularly good at it.
> 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).
I thought about that, but then we sort of have self-cancelling clauses
in Policy; sections that invalidate other sections or even themselves.
The thing as a whole may remain self-consistent, but it becomes very
confusing at that point.
You may be right that it's the best we can do at this point, but then
I think we should go all the way with this, and have Policy specify
the terms under which certain of its clauses become obsolete, and what
replaces them, rather than leaving that up in the air. If we're not
going to hard-code release names, then we need to make sure we don't
get stuck with a temporary policy as permanent policy somehow.
p.s. I find it much easier to debate these issues when you're
remaining calm and rational instead of hurling four-letter invective
around the place, which sometimes causes me to lose my own cool.
Let's see if we can keep this up. :-)
cheers
--
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: