Re: Proposed refactoring of the per-release tracker pages
On Fri, 8 Jan 2010 17:40:48 +0100, Moritz Muehlenhoff wrote:
> Michael Gilbert wrote:
> > In order to address some usability, clutter, and transparancy issues
> > with the tracker, I propose to make the following changes:
> >
> > 1. By default, the per-release pages (e.g. [0]) will only show low,
> > medium, and high urgencies.
>
> Plus issues where no severity is set.
See below.
> By default issues which are set <no-dsa> should not be displayed as well,
> since they're triaged security-wise.
Agreed.
> > 2. All blank urgencies will be converted to "undetermined".
>
> No way. <undetermined> should be used for fishy issues where no sufficient
> research has been done (like for the ltdl or expat mass bug filing, where
> 50% of the initial reports turn out to be false positives).
Agreed. I had spent some time contemplating the implications (shortly
after I hit send), and I concluded the same thing. <undetermined> is
definitely not right for these cases.
> 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.
Here is the logic: if the commiter really thought the urgency deserved
elevatation, then they would have manually set that. Instead since they
have not done this, then it can and should be concluded that it is one
of low-priority since it wasn't significant enough to set higher.
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?
I think the answers are: no, with confusion, to indicate that someone
needs to set an urgency, and no. So if it serves no real purpose, why
is it there?
Thank you for reading my long-winded response.
Best wishes,
Mike
[0] http://lists.debian.org/debian-security-tracker/2008/05/msg00026.html
[1] http://lists.debian.org/debian-security-tracker/2008/05/msg00031.html
[2] http://lists.alioth.debian.org/pipermail/secure-testing-team/2009-October/003286.html
Reply to: