Re: undetermined vs todo (was: [Secure-testing-commits] r15066 - data/CVE)
On Fri, 30 Jul 2010 14:41:59 +0200, Nico Golde wrote:
> Hi,
> * Moritz Muehlenhoff <jmm-guest@alioth.debian.org> [2010-07-29 23:49]:
> [...]
> > CVE-2010-2903 (Google Chrome before 5.0.375.125 performs unexpected truncation and ...)
> > - TODO: check
> > + - webkit <undetermined>
> > + - chromium-browser <undetermined>
> > CVE-2010-2902 (The SVG implementation in Google Chrome before 5.0.375.125 allows ...)
> > - TODO: check
> > + - webkit <undetermined>
> > + - chromium-browser <undetermined>
> [...]
> While I see all these undetermined bugs... What about changing the TODO: check
> to an undetermined status? The problem I currently see is that TODO issues are
> being worked on while undetermined issues mostly end up forgotten. And
> undetermined status is pretty much what TODO: check is anyway.
it's not quite the same since undetermined can be set on a per-package
basis, which i think is more robust/flexible. also, undetermined issues
show up in debsecan, which i use to keep track of issues that i may be
interested in working on.
i think Moritz uses that tracking for issues that he feels clutter the
TODO page, and that is ok with me. Guiseppe and i manually check
webkit/chromium issues anyway. i would prefer to display them by
default on the per-release tracker pages, but Moritz vetoed that.
i was planning to (when i find the time) to add <undetermined> entries
to the tracker's TODO page (with an option to hide that) to make them
more visible. also, i was thinking about including the TODO
message on that page as well to increase usability. lastly, i am
planning to update check-new-issues to stop on <undetermined> issues
even if there is no TODO (with a flag to not do that).
mike
Reply to: