Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
Hi,
>>"Chris" == Chris Waters <xtifr@dsp.net> writes:
Chris> Manoj Srivastava <srivasta@debian.org> writes:
>> I have a couple of things to say about this proposal. I think
>> that we have a bad track record when it comes to merely deferring the
>> issue until a latter date (I point to the archive reorg issue
Chris> Which is a political issue. We're bad at political issues -- we're
Chris> good at technical ones. This one is a technical one.
I think you arte thinking of the wrong reorg. The reorg I am
talking about was a technical solution to the huge number of release
critical bugs and the delays they entail -- it would have created an
incrementally updated stable pool of packages.
That was deferred, and is lost in the mists now.
>> Secondly, I think that the policy should not hard code release
>> names, we should just say that we are moving to the FHS, with a few
Chris> I STRONGLY disagree. If policy can't mention release names,
Chris> then we should create a formal strategy, which defines the
Chris> future direction of policy. We *need* to be able to plan for
Chris> the future, for situations like this. If policy continues to
Chris> ignore the release cycle, then ugly messes like this are just
Chris> going to arise again and again.
You can do all the planning without naming the code names.
Chris> A static policy may have been adequate when the system was
Chris> originally being built, and there was no release cycle, but
Chris> now that it's built, we need to start planning for *change*
Chris> instead of assuming that the system will be static for
Chris> eternity.
I think you are very confused. There was never a case when
there was no release cycle. And a strategy for change does not need
to be encapsulated in policy (though in this case I think we can
indeed encapsulate the changes without naming the release code name.
Chris> I'm guessing that there's just about zero chance that Santiago will
Chris> withdraw his objections to either proposal.
All the objections need not be withdrawn -- we just need one person.
>> Finally, the tech ctte may come forth with a proposed
>> transition; the DPL has asked the ctte to consider this problem.
Chris> As long as they have *all* the facts, and are aware of my proposal as
Chris> well as the bletcherous mandatory symlink proposal, fine. And as long
Chris> as they're aware of NEW objections to the ghastly mandatory symlink
Chris> proposal, like the requirement to add postinsts to all the packages
Chris> that currently lack them, possibly for eternity, certainly till at
Chris> least Woody+2 or +3 (which I wasn't aware of until *after* the
Chris> proposal was already mooted).
bletcherous? ghastly? This _is_ a technical discussion we are
having, right? (using emotionally laden words like that does littel
for credibility).
In any case, the ctte is far from unapprochable. If unbiased
reporting is much of a concern to you, just write to
debian-ctte@lists.debian.org. The list is also archived, so you can
have a look at what is being said.
manoj
--
Anything free is worth what you pay for it.
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: