On Fri, 30 Jul 2010 14:41:59 +0200, Nico Golde wrote: > Hi, > * Moritz Muehlenhoff <[email protected]> [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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
