Well that thought works well for CSDL's development and hackystat process, but for everyones. We need to think in the general sense.
----- Original Message ----- From: "(Cedric) Qin ZHANG" <[EMAIL PROTECTED]> Date: Friday, September 29, 2006 2:10 pm Subject: Re: [HACKYSTAT-DEV-L] Interesting problem in CodeIssue To: Aaron Akihisa Kagawa <[EMAIL PROTECTED]> Cc: [email protected] > I would claim it would be extremely unlikely that you would get rid > of > all code issues, since there are always issues that you don't care. > On > your chart, you can plot two lines: total code issues (almost > always > positive), and the issues you care (this one might go to zero). > This > will solve your problem with modifying any code. Cheers, -Cedric > > > > Aaron Akihisa Kagawa wrote: > > (1) CodeIssue is a snapshot analysis and is currently implemented > in that fashion. And I think it makes more sense as a snapshot > analysis. > > > > (2) An idea that I had would be to send the number of analyzed > files. Sort of like UnitTest where we send all files regardless if > there is a pass or fail. We could send all CodeIssue regardless if > a violation was found. To do this we would have to pass the src > directory to the sensor (again much like the Junit Sensor). > > > > Thanks, Aaron > > > > > > ----- Original Message ----- > > From: Philip Johnson <[EMAIL PROTECTED]> > > Date: Friday, September 29, 2006 10:01 am > > Subject: Re: [HACKYSTAT-DEV-L] Interesting problem in CodeIssue > > To: Aaron Akihisa Kagawa <[EMAIL PROTECTED]>, Discussion list > for hackystat developers <[email protected]> > > > > > >> It seems to me that there are two interesting issues here: > >> > >> (1) Should CodeIssue data be analyzed in a "latest snapshot" > fashion?>> > >> For example, with Coverage and FileMetric data, our analyses > assume > >> that > >> the latest obtained data is what the users want to know about. > >> > >> On the other hand, with DevEvent and UnitTest data, our analyses > >> assume > >> that users want to know about the "aggregate" results for a > given day. > >> > >> Currently, CodeIssues are analyzed in an "aggregate" fashion. I > >> think > >> arguments can be made for both approaches! > >> > >> (2) How to differentiate "0 issues found" from "sensor did not > run".>> > >> As Aaron notes, this has come up before. Basically, we need to > >> design the > >> sensor to be able to send an "empty" dataset and the analyses to > >> interpret > >> that correctly. > >> > >> Cheers, > >> Philip > >> > >> --On Wednesday, September 27, 2006 9:59 AM -1000 Aaron Akihisa > >> Kagawa > >> <[EMAIL PROTECTED]> wrote: > >> > >> > >>> Hey Guys, > >>> > >>> here is an interesting problem. I just fixed all the CodeIssues > >>> > >> in a > >> > >>> module and sent CodeIssue data. I ran the analyses to see if the > >>> CodeIssues went down to zero. It didn't. Hm... the problem is > >>> > >> that zero > >> > >>> CodeIssue means that no data is sent. Its just as though I > didn't > >>> > >> run the > >> > >>> sensor at all. I started to think about this problem a while > >>> > >> ago; see > >> > >>> http://hackydev.ics.hawaii.edu:8080/browse/HACK-393 . > >>> > >>> Anyone have any ideas on how to solve this? > >>> > >>> thanks, Aaron > >>> > >> > >> > >> > >> > >
