On Wed, Feb 20, 2002 at 10:39:18PM -0600, Manoj Srivastava wrote:
> Anthony> Actually, they are inflated.
> For some definition of inflated. These are serious bugs, in
> that they violate policy; they may not be deemed RC, and that is
> your prerogative.
The whole point of the "serious" severity is to catch RC bugs that aren't
"grave" or "critical".
> Anthony> It's not critical for woody's release to have these things
> Anthony> fixed: it doesn't really matter at all whether they're
> Anthony> fixed. Users won't particularly notice, and it's not
> Anthony> getting in the way of our development. It's a sensible thing
> Anthony> to fix for woody+1, but it's not release critical now.
> So as long as users do not notice, it is OK to have packages
> that do not build from source?
Well, basically, yeah. If no one notices a bug, it doesn't matter. Users
don't notice this, generally, and we as developers haven't cared enough
about it to even check 'til a week ago, so obviously it hasn't mattered
at all.
We're here to produce a high quality free operating system. Removing
packages because of bugs that don't actually cause anyone any problems
doesn't aid that goal.
That's not to say that having the binary-all target not work correctly
isn't a bug: it is, it's simply to say that it's not release critical.
(Which is to say, "OK" is ambiguous in what you wrote. Just because a bug
isn't RC, doesn't make it okay.)
> Anthony> OTOH, policy does say that packages must build, which these
> Anthony> don't, so according to the definition of "serious" (and
> Anthony> hence "release-critical"), these are. That's therefore a bug
> Anthony> in the way we define serious.
> No. It is a bug in the way we define RC. Really, RC bugs
> should be orthogonal to severities -- serious bugs are violations of
> policy -- period.
No, they're not. They're severe violations of policy. Minor violations of
policy (missing manpages, eg), aren't somehow more severe than segfault
bugs just because they're mentioned in policy.
(I don't believe I'm having this argument *again*)
> The release manager decides which bugs are RC,
> perhaps with a tag. By default, certain severities are automatically
> tagged RC. The RM comes and adjusts the tag.
> Simple. Clean. Orthogonal. Does not require artificial
> deflation of bug severities.
Except that it's not orthogonal, if it were you wouldn't have a default
that needs adjustment.
What's orthogonal is "mentioned in policy" and "severity". Serious bugs
are precisely those that aren't grace or critical, but are nevertheless
release critical. The more severe the bug is, the more severe the
response needs to be (a security update, dropped from the distribution,
an eventual fix from the maintainer).
It'd be orthogonal (and easy) to add a "policy" tag for bugs that
specifically violate a section of debian-policy (they could be grave
because they make the package uninstallable, or wishlist because they
don't implement some minor bit of functionality, or anything else). I
don't see a use for it, but it'd be possible.
> This is truly a bad idea. You are losing information (well, I
> guess one can dig into the bug history to figure out what the true
> severity needs to be) just because you are overloading the severity
> with the RC-ness of the bug.
This information ("this is an actual policy violation") could easily be
retained by a tag, if it was actually useful. Is it? How so?
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
We came. We Saw. We Conferenced. http://linux.conf.au/
``Debian: giving you the power to shoot yourself in each
toe individually.'' -- with kudos to Greg Lehey
Attachment:
pgpLT_AwsJ5fE.pgp
Description: PGP signature