Re: Proposed refactoring of the per-release tracker pages
On Sun, 10 Jan 2010 14:52:11 +0100, Moritz Muehlenhoff wrote:
> Michael Gilbert wrote:
>
> > > As said before the severity is irrelevant, hardly to classify and only
> > > used for some priorisation. They should not be mandatory.
> >
> > I personally think that urgency does have relevance, which I've
> > mentioned a few times before [0],[1],[2]. In particular, it is very
> > useful for those with an outside perspective (i.e. users that depend
> > on their OS to be trustworthy, but lack the skill to understand the
> > impact of security issues; and even for those users that are skillful
> > but don't have free time to spend studying each individual issue).
> > In summary, the advantages are:
> >
> > 1. A lot of open low-urgency issues in your operating seems like a much
> > better situation than a lot of open undefined severity issues. This is
> > especially important for the numerous users who don't have the
> > patience/skill to understand the impact themselves.
> >
> > 2. From an uncertainty perspective, if you have a system with three
> > states, but you don't have any information about which of those three
> > states the system is in, you have to assume the worst-case scenario.
> >
> > 3. From an internal (to the debian security team) perspective, it helps
> > to prioritize work, which is a good thing (although I read somewhere
> > that there is an RT system behind the scenes, so I don't know if that
> > supercedes urgency).
> >
> > Now, I understand that making urgencies mandatory has been deemed
> > undesirable from the team members, so that is not a good solution. But
> > on the other hand, I think they urgencies are very useful and
> > important. So we have two conflicting percpectives, but I think a
> > compromise can be made.
> >
> > I propose to show all unspecified urgencies as low in the tracker.
>
> That's only adding confusion. It often happens that we know that
> there is an issue (e.g. because an upstream mentioned it in the changelog),
> but noone had the time to look into it. It that case it should be tracked
> with unspecificed urgency, just as it's currently done.
This is the exact case where <undetermined> is meant to be used. Like I
mentioned before, <undetermined> is intended to supersede any other way
of tracking partially triaged issues.
> > Viewed from another perspective are the following questions. Is there
> > any real purpose for an unset urgency? How does the user interpret
> > that information? How is it useful? Does it make any kind of impact?
>
> Well, he interprets as an unknown urgency, I don't see how anyone can be
> confused about it.
The confusion arises from the fact that an unknown urgency is
meaningless (as well as the other reasons I stated above that weren't
rebutted). An undetermined state, on the other hand actually makes it
clear that the problem is being tracked, but more work needs to be
done; rather than saying just that an urgency needs to be determined.
It also adds a lot more clarity in the tracker pages.
Once again, I have again been rethinking this idea, and I am willing to
compromise further:
I propose to use the nvd urgency for all unspecified urgencies (and for
clarity there will be a double-star note in the tracker to describe
where that info was derived from).
Logic: the work to categorize the impart/urgency has already been done
(by supposed experts) elsewhere, so lets make use of it. Of course the
nvd analysis may be wrong, or it may not adhere to debian guidelines,
but of course it will remain possible to override the data for those
cases.
Mike
Reply to: