Re: Proposed refactoring of the per-release tracker pages
On Sat, 9 Jan 2010 17:26:43 +0100 Francesco Poli wrote:
> On Fri, 8 Jan 2010 17:59:52 -0500 Michael Gilbert wrote:
>
> [...]
> > I propose to show all unspecified urgencies as low in the tracker.
>
> FWIW, I don't think this is a good idea.
>
> >
> > 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.
>
> This would force the meaning of an unset urgency into being equivalent
> to a low urgency.
> IMHO, this would reduce the expressive power of the security tracker:
> to me, an unset urgency basically means "unclassified"; that is to say,
> something that could be low, medium, or even high, but requires further
> thinking before one can decide which is the correct category.
Thank you very much for your feedback. The new <undetermined> tag is
actually indended for the case you describe above. If the triager has
done enough work to decide that <undetermined> is not appropriate, then
they must have enough information to appropriately categorize the
issue. Hence, if they choose not to set the urgency, then it indicates
that they did not find it to be of elevated urgency.
> It avoids hiding the fact that some vulnerabilities still have to be
> classified, and hence are of uncertain urgency.
> I think that this should be considered as part of the "do not hide
> problems" philosophy (see SC #3).
These changes are not certainly not intended to hide anything. The new
<undetermined> functionality supercedes the old workflow.
Again, thank you for your insight.
Best wishes,
Mike
Reply to: