Greetings, hackers, After a couple of months spent lost in the wilderness of NSF ProposalLand, I have finally escaped and can now (happily) devote my attention to Hackystat software development issues. Thankfully, everyone has been cruising along and making progress despite (or perhaps because of) my absence from active hacking. I am sending out this email to bring everyone up to speed on where things are and what I hope we can accomplish over the next few months.
First, I'd like to get a quick public release (6.6) out the door. The motivation for this is the impending article in IEEE Software for July/August on Software Project Telemetry, which I anticipate will lead to a surge of registrations, downloads, and interest in the system. The good news is that we have the new multi-axis telemetry to show off. The bad news is that the docbook documentation (and, I believe, the public server definitions) have not yet been updated. So, I've done some editing in Jira to pare down the 6.6 release issues to the bare minimum and push the others out to Release 6.7. The current set of 6.6 issues are available at: <http://hackydev.ics.hawaii.edu:8080/secure/IssueNavigator.jspa?mode=hide&requestId=10070> The number of 6.6 open issues per developer are: 1 Cedric 1 Philip 1 Mike 2 Hongbing 2 Aaron Please check these out and try to close them by the end of this week if possible. Second, I'd like to summarize some of the major upcoming projects in Hackystat. * Evolutionary Sensor Data Types. [Philip] No, I haven't forgotten about this! Once I get the multi-axis telemetry documentation fixed, I am going to start hacking on this with a vengeance. * HackyInstaller integration. [James, Austen, Julie] As soon as the stable 6.6 release occurs, we will immediately begin to destabilize by integrating in our new groovy GUI for client-side sensor installation and maintenance. The result will be new '.installer' subpackages associated with each sensor which are combined together during a Hackystat build to create the associated hackyInstaller.jar program. Of course, we'll need to completely rewrite all of the DocBook documentation about client-side sensor installation. * DocBook configurability. [Philip initially, then Mike, Christoph, Hongbing, Takuya, Aaron, Cedric] The current DocBook documentation does not adequately support the configurable nature of Hackystat. For example, it should be possible for Aaron to create a DocBook chapter regarding the use of the PRI system that gets included into the help pages when (and only when) hackyPRI is included in a hackystat configuration. Just as we have a SensorManager and an SDTManager that dynamically determines what sensors and SDTs are available when the system comes up, we need to have a similar facility for docbook chapters. When this is done, we can basically move the chapter on telemetry to hackyTelemetry, and write new chapters for Priority Ranked Inspection (Aaron), Software Review (Takuya), Continuous GQM (Christoph), Software Development Stream Analysis (Hongbing), and Empirical Experimentation (Mike). As part of this, I am also going to extend the DocBook documentation representation to support three kinds of chapters: User Guide Chapters (what we have now), Administrator Guide Chapters (how to install and maintain the server), and Developer Guide Chapters (how to build things like Sensors, Sensor Data Types, Commands, Reduction Functions, PRI indicators, SDSA classification schemes, etc.) This is also going to be really cool, because, as you can see, most of our current research projects are designed in terms of an extensible API (such as Reduction Functions or PRI Indicators) along with an initial implementation done by the designer to support evaluation. So, really, we need two kinds of documentation: user-level documentation that explains how to use the system (i.e. how to use Telemetry, how to perform review, how to use PRI) as well as developer-level documentation that explains how to customize/enhance the system (i.e. how to write a Reduction Function, how to write a new PRI indicator, etc.) My grand scheme is that by the end of 2005, we will have all three types of documentation (user, administrator, and developer) available online as part of the Help page of a Hackystat server, and of course each configuration will include only the chapters appropriate for it. * Daily Build Failure Telemetry Study. [Cedric] Starting very soon now, and continuing through the rest of 2005 will be Cedric's study of daily build failures in Hackystat. He will be implementing machinery to provide automated support for understanding build failures, and seeing (via appropriate telemetry) whether the machinery helps reduce the rates of build failure. * Experimentation Framework in Hackystat. [Mike] Mike is off in Maryland for the summer, working with Victor Basili's group on, among other things, better support in Hackystat for empirical experimentation. * Miscellaneous fixes [Everyone]. While the above are the 'big ticket' items for Hackystat for the next several months, there are a bunch of smaller things we need to do as well. You can see the current set of 6.7 issues at: <http://hackydev.ics.hawaii.edu:8080/secure/IssueNavigator.jspa?mode=hide&requestId=10071> and the remaining unscheduled open issues at: <http://hackydev.ics.hawaii.edu:8080/secure/IssueNavigator.jspa?mode=hide&requestId=10061> I get occasional unsolicited email from people inquiring about server installation and so forth, which indicates that Hackystat is more and more capable of "escaping into the wild". As one example: <http://www.mail-archive.com/[email protected]/msg00939.html>. Currently we are actively supporting four installations: UH, University of Maryland, Sun Microsystems, and Ikayzo. By this time next year, I hope for an order of magnitude increase in both actively supported installations and the number of installations we hear about. If this wasn't enough work for us already, note that my NSF proposals describe a whole new set of interesting research and development tasks, from a federated network of hackystat servers, to the integration of data mining techniques for discovering developer best practices. For more info, see the technical reports: * Cedar: Cyberinfrastructure for empirical data analysis and reuse <http://csdl.ics.hawaii.edu/techreports/05-02/05-02.pdf> * A continuous, evidence-based approach to discovery and assessment of software engineering best practices <http://csdl.ics.hawaii.edu/techreports/05-05/05-05.pdf> Finally, just a heads up about the current transitions in the core Hackystat Hacker roster. Aaron, Takuya, and Christoph are finishing their M.S. theses this summer. We wish them the best of luck and hope they will be able to continue contributing to the project after they graduate. Julie, Austen, and James have just joined the project and we hope to keep them ensnared in hackystat development for the foreseeable future. Hongbing, Cedric, and Mike continue to blast away on their Ph.D. projects; at this point Cedric is closest to seeing the light at the end of the tunnel. Comments, questions, reactions? Cheers, Philip p.s. Don't forget about submitting to the telemetry plate lunch contest! <http://www.mail-archive.com/[email protected]/msg00950.html>
