I probably don't know enough to even ask the question, but isn't this something you can just include in the daily build to guarantee you get a snapshot every day?
Maven has a JIRA task that downloads the open issues as XML and then formats them into HTML reports when it builds its project documentation. There's a Java class that simply downloads the file needed to support the Maven work. It'd seem possible to take the next step and send that data to the Hackystat server. http://maven.apache.org/reference/plugins/jira/faq.html The source is browsable here: http://cvs.apache.org/viewcvs.cgi/maven-plugins/jira/ Then you'd have a sensor that sits on the build side of things, and can poll for the snapshot any time its needed. That may currently be the case with the Jira sensor, though, since I don't know much about it. On Wed, 17 Nov 2004 14:40:54 -1000, Philip Johnson <[EMAIL PROTECTED]> wrote: > I met with Burt and went over the issues, but it's probably good to get them > down in > writing. > > First off, we know the following: > > 1. Sensor data collection is inherently unreliable. We can't guarantee > 'perfect' data > collection. > 2. Telemetry should degrade gracefully; we shouldn't require complete data to > do useful > analyses. > 3. In the domain of issue management, the number of current open issues is > probably the > number one most useful telemetry stream. > > Unfortunately, the current design of the Issue sensor makes (3) problematic: > - we won't have all of the Issue events available to us; > - we would have to search through all our records and 'reconstruct' which > are open; > - we will need to have a complete history of the issues from the start of > the issue > management system > > An alternative approach to getting (3) is a kind of 'snapshot' mechanism, in > which the > Jira sensor wakes up once a day, queries Jira for the set of open issues, and > emits a set > of specially indicated Issue events that comprise a 'snapshot' of the open > issues on that > day. We could 'specially indicate' these issues by including a key-value > pair in the > data field such as OpenIssueSnapshot=<timestamp>, where all of the open > issues in this > list would share the same timestamp value. (That would enable the sensor to > send it twice > in one day and allow the telemetry stream to use only the last received set). > > This would not replace the current mechanism, it would simply supplement it. > > Finally, we would need to indicate which account should receive this data. I > suggest an > extension to the usermapping system to enable us to indicate, for example, > that > hackystat-l should get this data. > > Cheers, > Philip > >
