On Mon, Nov 11, 2002 at 02:36:44PM -0500, Branden Robinson wrote:
> [-project and -policy, I CCed you because I'm raising issues relevant to
> you; *please* honor the Mail-Followup-To: header!]
The one that says only post to the bug and -ctte? Weird. I don't think
any of the following is likely to be useful to the ctte's further
deliberations, so retitled and moved to -project; -ctte and branden
Cc'ed for their convenience. M-F-T hopefully set to -project.
> On Tue, Nov 12, 2002 at 02:28:34AM +1000, Anthony Towns wrote:
> > (1) All bugs have an objectively defined severity, which can be
> > determined by reference to the bug submission guidelines,
> > policy, and similar resources. The principle is that bugs
> > that have a similar effect should have a similar severity.
> This is a pretty low level of objectivity, in practice. So much so that
> I think it's overstating the case to assert that "all bugs have an
> objectively defined severity".
*shrug* You're welcome to your own opinion. The key point is the last
sentence: that bugs that have a similar effect have a similar severity.
> Not pefectly, though: consider the fact that
> folks routinely file grave or even critical bugs aginst X server
> packages because the X server doesn't support their video hardware.
> For them, "the package in question is unusable".
They're wrong; either in that they've misinterpreted the guidelines
for "grave", or in that they haven't fully investigated/understood
the problem. Either's entirely reasonable.
> I worked with Chris Lawrence to sneak slightly improved definitions of
> the bug severities into the reportbug package, and this has in fact
> helped with severity inflation for X server bugs.
(There doesn't seem to be a bugreport against bugs.debian.org about this)
> How about having only *some* of the bug severities be deliberately
> objective? How about leaving the others to the maintainer's discretion?
*shrug* I only really care about the bugs I have to be responsible for,
which are my own and the RC ones.
> critical
> grave
> -------------- objectivity threshold
> serious
> -------------- "RCness" threshold
I'm happy to consider "serious" to be "objective" as is, since it names
the oracle(s) you have to use to evaluate any subjective portions. You're
welcome to quibble over the appropriate term to use, but the effect is
what's important: that similar bugs have similar severities, and that it's
easy for submitters to determine that RC bugs should be filed as such.
Probably the important property is here is "the release manager's
judgement is not required for determining the RCness of a bug, and in
the normal case the maintainer's judgement isn't either". I presume you
can at least see the bottlenecks that's trying to avoid?
> * The current imperfection of the Debian Policy Manual causes us to lend
> more gravity to certain bugs, as a result of "a severe violation of
> Debian policy (that is, it violates a "must" or "required"
> directive)," than they deserve.
No, this isn't the case. The "requirements" of the policy manual are
what has previously been called "release goals" -- they're the things
that we're insisting we achieve before we'll release. The gravity we
lend to issues from the policy manual are entirely due to this, and one
of our release goals is FHS compliance, in every single way.
You, personally, can obviously disagree on the sense of that course of
action, but Debian has decided that it will treat FHS compliance as a
major issue and devote a lot of effort to getting it right, and, like
DFSG-freeness, security issues, and so forth, it's not one that's left
up to the package maintainer's discretion.
> I suggest that until that day comes, or at least
> until it's visible on the horizon, we not have the "serious" severity
> drafted into service as a maul wielded to enforce Policy.
It's not drafted into service to enforce debian-policy; it was *created*
as a way of tracking packages' problems in achieving release goals --
which happen to be documented in policy.
> As far as I can recall, I have yet to encounter anyone who can tell me
> with a straight face that #97671 is a big deal.
Bug#143825 is a big deal -- it's a trivial instance of standards
non-compliance that should have been patched around a year and a half ago.
I think it also happens to be the standards-compliance issue that we've
known about longest, of those still present in unstable as of today. (As of
today, a bunch of the bugs marked [REMOVE] in the RC bug list have been
removed from unstable)
> If we have a BTS that leads me, or other people, to spend
> time on this bug rather than, say, finding racy symlink-attack
> vulnerabilities in xdm, I think that's a misfeature of the BTS.
It's not: symlink-attack vulnerabilities in xdm will generally be critical
(severe data loss/security hole) or grave (data loss/user security hole).
> Please, let's isolate the damage from Policy flamewars.
That's a nice aim, but it's _much_ more important not to dump all the work
of keeping the release-critical bugs organised onto the release manager.
> I don't know
> what the Policy Manual will look like in a year or two years, but I do
> know that its current imperfections, or the threat of it falling into
> an unmaintained state if something bad should happen to Manoj, should
> not have disruptive effects on the Debian BTS.
That might be correct, but it's a non-sequitur. The obvious solution (to
me), is not to change the way things work, but to fix the imperfections
in policy and to make sure it doesn't become unmaintained.
> > [...] and for sarge it will probably
> > a real "ignore" or "allow-release" tag. [...]
> Well, why not encapsulate this information into the BTS via tags?
*cough*
> A high severity is good for getting your (the RM's) attention.
No, it's not. Seriously: you've said this a bunch of times, and I've heard
you, but I still disagree. It's _not_ about getting the release manager's
attention, it's about distributing the workload of managing the release.
So that it's not all on one person's shoulders, and so that the quality
of Debian's releases aren't solely dependent on the whims of a single
person (and this particularly sucks, because IME it's hard to even be
consistent with yourself on this when there's no set of guidelines that
at least attempts to be objective).
Now there are cases when this isn't the case; but it's around 2% of all
bugs filed (we have ~600 RC bugs at the moment, we usually have about
a dozen bugs that get legitimately ignored). We absolutely _must_ make
the behaviour for the 98% the normal case.
> You
> often want to keep track of a bug so filed, sometimes regardless of
> whether the severity was inflated in the first place -- even according
> to objective criteria -- or not.
I'm not sure I ever really keep track of bugs at a severity below serious,
actually -- usually I'll email the maintainer to see if they feel it'd
be better made serious, and if they don't practice saying "It's all <the
maintainer>'s fault!" in the mirror. There are unfiled bugs I have to
keep track of, unfortunately, too. But there're rarely more than one
or two bugs like that at any one time, which makes them even less worth
focussing on.
> The severity may go up or down, but
> that's not in and of itself determinative of whether you care about it
> or not.
Except when people misunderstand the point of the severities, it _is_
fairly determinative in about 98% of cases. And people have actually
been fairly good about getting the severities right these days, the
occassional undiscussed mass bug filing withstanding.
> [Consider our recent discussion regarding 4.2.1-3, #97671, and
> propagation testing. Among other things I didn't know, I didn't know if
> you were still paying attention to that bug or not.
I'm trying to pay attention to all the bugs in the RC bug list, ie all
bugs that have severity "serious" or above.
> I'm not wedded to the name or semantics of a "release-critical" tag.
> I think the right thing to do is to equip the BTS with a device that
> lets the Release Manager do his job efficiently. I think a tag is it.
I think the "serious", "grave" and "critical" severities are it.
Seriously, they're actually working pretty well. Policy not handling
release goals well is annoying, but not as bad as "important" was; and
debbugs not coping with testing is horrible, but that's a completely
independent issue.
> By the same token, I don't think there's any real value in having the
> BTS treat policy violations specially for triage purposes.
Again, the issue isn't "policy violations", but "unachieved release
goals". The difference is that of "long description is uninformative"
and "non-free software in main".
Maybe:
serious
- is a severe violation of Debian policy (that is, it violates a
- "must" or "required" directive), or, in the package
+ is a violation of a release goal (that is, a "must" or "required"
+ directive in Debian policy), or, in the package
maintainer's opinion, makes the package unsuitable for release.
would make this clearer and more intuitive. "production environments"
sounds like a much better term for the latter half, too.
> > although generalising it to allow the maintainer to arbitrarily
> > re-prioritise bugs would probably be a win -- the idea being you could use
> > a different URL and get the bugs in the order in which the maintainer will
> > be focussing on them. (Which is to say, I won't be writing or applying
> > any patches for the former, although someone else on owner@bugs might, but
> > I'd probably be interested in seeing patches or good ideas for the latter)
> Bugzilla has two different fields. "Severity" and "Priority". I'm
> pretty sure I think that's a good idea, but as you say, you're not
> willing to do it.
No, _that_ (or something like it) I'm happy to do. Discussion should be
on debian-debbugs@lists.debian.org or -devel or similar, not as part of
this thread though.
> > An inaccurate "pending" tag probably makes it
> > less likely for people to provide patches, etc, which would presumably
> > be a loss. Apologies if the assumption's incorrect, of course.
> It's not inaccurate;
Hrm, it's not either. I thought "pending" was meant to be "this bug has
been fixed and will be in the archive RSN". I wonder why it's not.
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.
``If you don't do it now, you'll be one year older when you do.''
Attachment:
pgpgm24vNPocz.pgp
Description: PGP signature