Re: Proposed refactoring of the per-release tracker pages
On Mon, 11 Jan 2010 19:28:48 +0100, Moritz Muehlenhoff wrote:
> On Mon, Jan 11, 2010 at 11:59:32AM -0500, Michael Gilbert wrote:
> > 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.
>
> Urgencies should not be mandatory, I don't add them currently in most cases
> and I don't intend to do so in the future.
As I said before, I have compromised on my viewpoint so that this will
not be the case.
> <undetermined> can be useful if we have a large scale amount of dubious issues
> which need further investigation, but not for the standard case, where we know
> pretty exactly that a vulnerability exists (usually because it's mentioned
> in an upstream changelog).
<undetermined> is not meant for "dubious" issues. It is meant for any
issue that needs further investigation before declaring fixed/unfixed.
See documentation [0].
> I don't have time for a lengthy discussion about this.
Discussion is healthy (although I think we've pretty much reached a
conclusion/consensus at this point).
> To summarise:
> Don't change the current workflow. You're free to add a new issue status, but
> don't cause regressions in the current way things operate.
Any workflow changes will happen due to free will adoption of the new
features. I do not intend to force anyone to do anything.
> > 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.
>
> As long as there's a disclaimer that NVD is automatically computed and
> often completely senseless I'm fine with it.
Agreed. Like I said, that's the plan (but the note will use kinder
language).
Mike
[0] http://lists.debian.org/debian-security-tracker/2010/01/msg00014.html
Reply to: