Re: Release-critical bugs, and #97671
Manoj Srivastava writes ("Re: Release-critical bugs, and #97671"):
> Ian Jackson <ian@davenant.greenend.org.uk> writes:
> > But, that doesn't mean that the severities need to remain set by
> > those objective criteria. Someone other than the submitter,
> > with a greater overview of the whole package or distribution,
> > might have a better idea, and might reasonably apply subjective
> > judgement.
>
> To what end? Why make the objective criteria malleable? When
> one discards objective criteria for classifying bugs, one merely
> opens the door for more disruptive disagreements between reporters,
> and even fellow maintainers. With around a 1000 developers and
> counting, there is unlikely to be agreement amongst developers.
Perhaps this will be an aside, or an attack on a straw man, but:
I seem to get the impression that you want to try to generally reduce
subjective judgements, and discretion. I think this is a deeply
flawed goal. We rely absolutely on the good judgement of our
maintainers and other members of the project, and I don't see how it
could be any other way. If it were possible to produce a good
distribution without using the judgement of good people, it would be a
lot easier, it's true, but I think it's not at all possible.
Any attempt to do this will result in a tendency towards blind
application of rules, rather than detailed understanding of particular
cases, which seems to me to be the very opposite of what is required
when doing system integration. The hard bits of system integration
are all about special cases.
We have plenty of mechanisms for helping people excercise judgement
wisely, and in extremis we also have the Technical Committee, who can
overrule something that is sufficiently clearly a mistake. I think we
should be relying on these.
I think the best way to resolve arguments is to make sure that it is
clear in whose bailiwick a certain decision falls, and having a
well-functioning escalation procedure, rather than trying to make
every decision objective.
So, on to the actual question at hand, here: you want to try to make
the bug severity criteria objective. What purpose do you think the
severity classification serves ? It seems to me that Branden was
trying to use it the BTS to help manage his worklist, and that he
wanted to use the severities to do so.
This is, it seems to me, exactly what the severities were originally
intended for, and if we think that that's what they're for, it seems
clear that the package maintainer is generally authoritative for the
severity of a bug.
Your recollection may disagree with mine, but if so I'd like you to go
into more detail about what the purpose was/is. You say:
> [The severity] represents impact on the system. It categorizes
> the bug. It helps people understand potential damage the bug could
> cause, at a glance. It keeps packages out of testing. Releases
> occur farly seldom, and whether a certain version of a package is
> releasable or not is of importance to a small number of people for
> relatively short intervals of time.
I think these are all different and in some cases conflicting
functions.
* If the severity is supposed to be objectively determined by the
policy manual, I don't see how it could represent impact on the
system; furthermore, depending how you interpret `impact on the
system' it might well correspond fairly closely to a notion of how
high a priority the bug was on a notional todo list.
* Clearly it `categorises the bug' - that's tautological for a
classification. But *why* is the categorisation useful ? You could
categorise bugs by the hair colour of the first submitter, which would
be an objective classification but not particularly useful :-).
* Using severities to keep packages out of testing is using them to
keep a certain kind of releaseability information; not releasability
into stable, but nevertheless a releaseability. Furthermore, reading
between the lines, I get the impression that the release manager
doesn't deal with this particular question. If indeed this is what's
going on then it's not surprising we have a conflict, because we have
a decision whose owner is not clear.
> When you bring in policy conformance, and RCness, the
> maintainer may no longer be the one with the best knowledge of the
> issues.
>
> Also, just because a person is the maintainer does not mean
> they are more knowledeable than the reporter. (I would prefer not to
> name names here).
This is true, of course, but I think that any attempt to fix this by
trying to remove subjectivity is doomed. You can't save clueless
maintainers' packages by giving them a rulebook to follow, and clueful
maintainers will spend all their lives arguing with the rulebook.
If a maintainer is not up to scratch then you should appeal their
mistakes to the committee, or offer to take over the package, or
perhaps even prepare a rival version of the package and allow the
committee to decide between them (or carry out some other mechanism
for a `hostile takeover').
> > The question is then, what other useful information can we use it to
> > record, or are we trying to use it to record, in a way that supports
> > everyone in our work ?
...
> I think we should stop overloading the BTS for a TODO list for
> the project and developers. In this day and age we have better tools
> both for personal todo lists, and groupware products for the project.
>
> If the project thinks it is so important, why do we not set up
> a wicki? or other such tool? It is easy enough to do so.
I think that the BTS has always been a TODO list. That's the way I
intended to set it up. IMO it's mainly function is to be a resource
to help the maintainers make sure that everything is dealt with, and
that the most important things are done first.
> > For some bugs, namely approximately the ones corresponding to
> > the current definitions of severity levels grave and critical,
> > it is very important to the whole project to get them fixed,
> > because they have bad effects which spread far beyond frequent
> > users of the package. These bugs are high-priority work items
> > for the whole distribution.
>
> Quite so. And a maintainer should not have the discretion to
> junk the objective criteria and label them wishlist on a whim, ot
> because they do not want to work on it, or it is too hard to fix
> right now.
Eh ? We can't insist that the maintainer do work for us. Whether
they label the bug wishlist or not is irrelevant, in the end: what
matters is whether it gets fixed. If the maintainer refuses to accept
the patch we have mechanisms for dealing with that. If the maintainer
refuses to work on the problem because they don't think it's important
then whoever cares so deeply about it will have to do the work.
Now some bugs - those I describe above - are sufficiently serious that
we want them high up the whole project's todo list, which means that
we need to override the maintainer's view of their importance.
> > For most other bugs, the package maintainer, and other people
> > closely involved with the package, are in the best position to
> > decide which bugs are the most serious and which should be
> > worked on first.
>
> Quite so. And if they do not violate policy must directives,
> for the most part they can.
Why do you think a violation of a policy must is necessarily the most
serious kind of bug ? I think it's plain that the policy manual can't
predict the impact of a particular kind of bug. (Indeed, the bug
which started all this seems quite unimportant, really.)
> I do follow the argument, but I do not agree, I think we
> should stop overloading the BTS, and use it for the primary purpose
> _first_, especially if it causes friction between reporters and
> maintainers about the severities. And it shall, I fear.
I'm afraid I'm still very unclear about what you think the BTS, and
its severities, are primarily for.
Ian.
--
To UNSUBSCRIBE, email to debian-ctte-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: