On Tue, Mar 06, 2001 at 12:07:20AM -0500, Ben Collins wrote:
> On Tue, Mar 06, 2001 at 10:24:41AM +1000, Anthony Towns wrote:
> > On Mon, Mar 05, 2001 at 09:01:23AM -0500, Ben Collins wrote:
> > > IMO, it should say "packages SHOULD change the docs to match the package
> > > setup", and "there MUST be a disclaimer when docs do not match the
> > > package", and "the disclaimer SHOULD be in the upstream doc itself, or in
> > > a the README.Debian if not".
> > Give me a break. You want a package removed from the archive, just
> > because it doesn't have a disclaimer about buggy docs?
> If the maintainer can't add "The docs reference paths that do not exist
> on a Debian system" to README.Debian, then I would think something is
> severely wrong with how the package is maintained.
Quite possibly. I'm sure you think there're problems with the way most
of my packages are being maintained too, and to be honest there is. There
are lots of open bugs that should've been fixed a while ago.
> Why is it that whenever something is proposed as a MUST, people always
> resort to "you really want to remove packages for reason <foo>?"
Because that is what "must" means. If you don't want to remove packages,
the guidelines should be expressed as a "should", not a "must".
> I mean,
> this is a simple request, and a simple thing to do, and for consistency
> sake, it's all the better that it be done. It doesn't mean it will be
> removed, it means someone has to fix the bug. Plain and simple.
(Here we go again)
_NO_. This is completely mistaken and bogus. You are completely wrong in
making that statement.
Packages with RC bugs, packages violating policy requirements (musts)
get pulled. That's what RC bugs, and MUSTs, are for. They don't have any
other purpose; they're not there to give us a bigger or sharper stick
for beating inactive maintainers over the head with, they're not there
to differentiate between which guidelines are easy and which are hard;
they're there simply to set an absolute minimum standard for inclusion
in a Debian release.
It's in policy because it's better to have it documented than left to
the release manager's whim.
I'm running out of ways to say this, and I'm not really convinced shouting
helps, but this really really needs to sink in.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
Attachment:
pgpfoA2f1cAZR.pgp
Description: PGP signature