I like the idea of the snapshot data collection but I have a few concerns. Firstly, how will this be implemented? Will this be a new SDT or a reimplementation of the issue SDT? I suppose in terms of my thesis research I could just manually examine the issues in Jira so an SDT that only collects # of open issues would not be a problem. Or I could change my thesis topic but I'm worried I might not have enough time.
Another concern is that this implementation seems inflexible. What if, in about 3 months, we decide that other types of unsupported status information are desirable? For example, the number of issues closed on a given day, the number of issues actively worked on by a person, the level of discussion happening on a given issue, the average number of updates on an issue, etc. It could be that we decide on a specific characteristic now (currently the number of open issues on a day) and then change out minds a little later. Burt > -----Original Message----- > From: Philip Johnson [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 16, 2004 3:24 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Disabling offline data storage/retrieval in Jira/CVS sensors. > > Pursuant to the discussion today between Cedric, Aaron, and I regarding > the > Jira sensor: > > SensorShell has a constructor that allows you to pass in a boolean that, > if > set to false, disables offline data storage/retrieval. Both hackyCVS and > hackyJira need to use that constructor. This is because the current > implementation of offline data storage is designed around the assumption > that the sensor.properties file can be used to determine the user and > host. > > > This is not the case for the CVS and Jira sensors, which use the > usermapping approach to determine user and host. Thus, the offline > mechanism won't work correctly. It is thus best to explicitly disable it > in the sensor so that it's clear that this utility is not being used in > this case. > > This brings up a new issue: what happens when the server goes down, since > offline data storage will not work?. We need to think about the design > implications of this, particularly with respect to the Jira sensor. It is > probably unsafe to assume that the current 'active' approach to sensing > will provide a 'complete' record of activities in the Jira server. This > impacts strongly on the kinds of analyses we can do on this data. > > Aaron, Cedric and I were talking about adding a 'snapshot' style of data > collection to the Jira sensor that would send data regarding only the > current open issues once a day. This would be one way to ameliorate the > impact of our inability to guarantee complete records of jira server > activity, and support a telemetry stream on open issues for a given > project > (which is probably the most useful analysis we could provide). > > Cheers, > Philip
