On Sun, Aug 29, 1999 at 02:22:15AM -0500, Manoj Srivastava wrote:
> Hi,
> >>"Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:
> Anthony> Then those packages are welcome to stay in /usr/doc, if
> Anthony> complying with the transition strategy irks the maintainer
> Anthony> too much. When policy changes, they'll just have to be
> Anthony> prepared to move more or less immediately, without as much
> Anthony> time for debugging as everyone else had.
> I guess I am confused about this now. How can policy change
> suddenly, since it makes other packages buggy? Does this mean the
> tech ctte has to get involved? How many packages is it OK for policy
> to ``suddenly make buggy''?
First, let me weasel out of this. My summary of Raul's statement was:
] The -policy group shouldn't change policy to declare that all
] packages are buggy. (and hence the FHS policy change was badly
] formulated)
That was declaring >all< packages to buggy. So clearly, when we change
in future a number of packages will have already converted, and we won't
violate that.
But that's complete BS of course --- breaking 2999 packages instead of
3000 isn't particularly better.
Unfortunately, I'm not really sure where the line is --- but I do think
declaring, ummm, 4074 odd packages in violation of policy in one stroke
of a virtual pen is crossing it.
Let me put it another way. Instead of expecting all 500 odd maintainers
to know which bits of policy the policy group currently expects to be
followed verbatim, and which bits it's okay to be lax about, it'd be
better to specifically say so.
Let me put it yet another way. We should be willing to add a lintian
check for any additions to policy, and file severity: normal bug reports
for every package in violation. (Which isn't to say we actually *should*,
but we shouldn't make policy where that would be unreasonable)
Does any of that make more sense, and/or seem a reasonable way of avoiding
making the same sort of stuff-up again?
> Is a policy that merely codifies existing practice worth
> having?
Yes, certainly. It lets you build a system that fits together nicely,
even if it doesn't let you improve the way things fit together over time.
But policy can and should be more than this, yes.
> And is the current reading that the -policy mailing list has
> no authority to change policy, so this mailing list is now defunct?
Heaven forbid. And if it is the current reading, then the tech ctte should
act to rectify it as soon as possible, which seemed to me to be what Raul
was saying.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
Attachment:
pgp_bOEWxs2yC.pgp
Description: PGP signature