Hey Guys,
Take a look at today's (March 1) Daily Project Details analysis for the hacky2004-all project. As of 11:00pm these are my observations:
First, you will notice that there are no FileMetric (as I wrote this email someone other than hackystat-l sent FileMetric Data), UnitTest, Coverage, Issues, etc Data that usually are collected using hackystat-l. I assume that Cruise Control did not run. Why is that? I remember hearing something about Cruise Control only runs when no changes were made to any of the modules. Is that true? If so, why not just build the system any way? If we don't run a build every day, there will be missing data points in analyses. By looking at the streams, it will be difficult to determine why there is no data. Possible reasons could be, the build failed, the sensor wasn't working, the system didn't build etc. Lets take one of those variables out of the picture by just building the system regardless if there are any changes. It isn't like we are saving resources by not building.
Second, you will notice that Takuya has about 1.17 hours of active time and no Builds (or his sensor is not enabled). That's a strange development process. Furthermore, he hasn't ran any Unit Tests (or his sensor is not enabled).
Third, you will notice that Hongbing just built the system 14 times and no ActiveTime. That is also strange. (I assume he is working on Zoro). Hongbing also hasn't ran any Unit Tests (or his sensor is not enabled).
Forth, apparently I ran a build today but, I'm pretty sure I didn't run a real "Build". A build, in my mind, is a compilation or testing of the system. Actually, I did a "ant cvsUpdateAll". Why is that considered as a "Build"? It really is an Ant Target invocation, not a Build. When would that be interesting? (Maybe Hongbing did 14 cvsUpdateAll's?)
Fifth, the CVS sensor isn't working. I know Cedric is aware of this, I know he is swamped with other stuff as we all are, but luckily we have a retrospective CVS sensor. Its a little strange that the sensor can stop working and the Unit Test all pass, assuming of course that the sensor is up-to-date.
To conclude, I propose that all Hackystat developers enable all sensors, except LOCC, Coverage, Jira, and Performace. At least, this will eliminate questions like, I wonder if he didn't build the system or doesn't have the sensor enabled. We talk about decreasing the build failure rate but we don't have all the information possible to make that happen. We should also be building using Cruise Control everyday. I can only see positives and no negatives.
Also, I'd like to throw out a concern of mine.. LOCC an Coverage are snap-shot type product measures. In our Hackystat process, we have a single user (hackystat-l) that is responsible for sending these measures. We do that partially because we don't want to clobber the "real snap-shot" with something we do for own local configurations. For example, say we all enabled LOCC and/or Coverage and sent data the information in those DailyProjectData representations will be fairly unreliable. By the way, I'm experiencing this problem right now in the Clew2-UH project. I act as a manual hackystat-l by building the Full System as much as possible. Then comes along a developer who has to have their sensor enabled for their other project, which contains a smaller set of workspaces, and clobbers the "good" data. In our Hackystat process we made a "hack", with hackystat-l, to fix that problem. In other situations this will be annoying. One solution could be a project level declaration of the "daily build user". Another, solution is to make a runtime map per workspace/file pattern. Therefore, even though a developer clobbers the data with a smaller set of workspaces the original workspaces "shine" through. That has some potential data integrity problems, however so does clobbering.
thanks, aaron
