--On Friday, January 27, 2006 8:23 PM -1000 Aaron Kagawa
<[EMAIL PROTECTED]> wrote:
Sounds like a good idea. But, what advantage other than reducing
redundant information would this provide? After all, CodeIssue,
FileMetric, Coverage, UnitTest, and Dependency data that all have much
more redundant information. On the other hand, I'm all for it if the
exploration becomes easier or if some way linking Issue data with other
data becomes easier. I think that is the key.
Well, I agree that other types of data are also "redundant" at some level.
I was hoping in the case of Issue data to reduce this, but who knows if we
can pull it off :-)
Maybe we can make the Jira sensor smarter? For example, maybe we have to
give in and actually hook into the database to send 'Age' data instead of
trying to calculate it on the server side.
Yes, that's a great idea and something we should explore in the longer
term----moving computation from the server to the sensor side. The problem
is that when we write a bugzilla or a clearcase or a whatever sensor, we
would have to implement the 'smartness' in each of them. Ultimately, we
might want to refactor it into the sensorshell (i.e. have the Issue SDT
contain methods to compute this stuff before sending it).
CSDL's use of the Jira-Subversion sensor and the process that we are
following opens up a lot of possibilities for linking ActiveTime,
Commits, and Issues.
I am violently in agreement with this one. There are incredible
workflow-related opportunities now that we can connect a high-level issue
with the low-level files _and_ a time interval that they were worked on.
This may evolve into a "killer app" for Hackystat: we can now hook together
all of our static and dynamic data with the high-level _intent_ of the
programmer as represented by the Issue.
One of the problems that I see with the event
based Issue SDT is that a commit for an Issue (specified with the
[HACK-1] convention) is not represented in the XML issue file. Thus, our
Jira sensor would not know to send Issue data and this link might not be
able to be made easily.
Wow, you're right; it may be hard to do 'incremental' Issue data sending
and still know to send updated information when the set of Subversion
commit records is updated.
I still think that the idea of having an Issue and an IssueSnapshot SDT has
merit, since the IssueSnapshot provides a way to represent client-side
analysis of the issue management state.
Maybe what we need to do in the shorter run is investigate sending Issues
representing a smaller segment of the issue repository each day. For
example, we may decide that the only issues to send right now are those
whose FixRelease is 7.3, and to do that we can provide some sort of
argument to the Ant sensor saying how to filter the issues to send.
Anyway, all of this is further evidence why (a) we keep hammering away at
Issue analysis, and (b) why we can't seem to easily find a simple obvious
solution to the correct approach to Issue analysis!
Cheers,
Philip
