CS 481 - Team 49 Meeting Minutes Weekly Team Meeting Friday, September 21, 2007 10:30 - 11:30 AM JEB 324 Recorder: Brandon Riggers -------------------------------- Meeting Summary This meeting involved discussion with Bill and Bruce about the contents and work necessary for our first release. In particular, we talked about the decisions of which diff utility and version of Perl to go with, some functionalities our product might or should include, and the documents to be included in the first release. The meeting concluded with Bill talking to us about the details of the certain design documents we'll be producing, including the Operational and Design Specifications, and defects. Attendees Brandon Riggers, Shruti Upadhyaya, Peter Brown-Hayes, Bill Junk, Bruce Mayes (over the phone) Topics Discussed Bill began the meeting by briefly addressing our task list and mentioning that we need to update it to include all the tasks that will take us through the first release. Bill also mentioned that this release will take more work than a traditional academic exercise. Our product will have to be well-tested and stable, and we'll need to know what it does. Bruce first talked about our design documents, and brought up the need for us to have a shared understanding. Bill explained that our Op Spec will come first, and will capture the requirements for the project. Bruce mentioned that writing this document will help us gather our thoughts, and he wants to "get everything all into one place." Bill also mentioned that writing code and the Op Spec during the same time frame will raise risk. Also, we need to get the final svn diff investigation findings to Bruce soon. The discussion shifted to the behavior of our tool. Bruce brought up the two general use cases and said that with a firmware build, our tool will be given a file list. With a single commit, however, will our tool get its own file list? Because the Cruise Control tool know the list of files changed, maybe our tool can get this list from Cruise Control. Bill added briefly that it would be nice if the interface was the same for the two general use cases. Bruce went on to say that the output is different for these cases, and that Cruise Control is not fired on its own. Peter brought up the idea of manipulating how Cruise Control is called, depending on the use case, and high-level scripts can be run after the metrics engine. Bill brought up the idea of "decoupling the system", where these functionalities get broken up. Bruce then began to discuss release 1, and confirming what he'll get. On October 5, he can get a tar-ball of all the deliverables, or, as Bill mentioned, we could just send Bruce a release message with a link to the release on our web site. Bruce said he needed a little time ahead in order to give us feedback on this first release. (So, if we wanted feedback on the Friday of our meeting, we should get Bruce the release a day ahead - October 4.) Bill suggested, however, that we make no promises pertaining to anything early, saying that "quality is of the essence." The first release is to include all our tests, complete documentation, and the code itself. The teleconference portion of the meeting concluded with Bruce talking about the possibility - or "mode" - of running our tool on some files, independent of Subversion. Bruce said he could picture a small number of tests that test the functionality of our tool outside of SVN, and can see the merit in having this ability. We discussed this breifly, and Bruce tried svn diff on two plain files while on the phone. Svn diff gave a "not a working copy" error. After Bruce was off the phone, Bill got a quick summary of our accomplishments from the prior week. He again addressed the need to update our task list to include everything needed for release 1. Bill then talked about some of these tasks and what we need for the release, which includes the Op Spec. This document needs to have a good command line definition (which may include the version of Perl we're using), and a good output definition. We'll also need a Test Specification, which consists of one to two pages that explain how we're approaching the testing, as well as one or two sentences that describe the purpose of each test. Bill mentioned that our design documents are evolutionary, and that we "can't live without code that's well-tested," but we "can live without documentation." Bill continued by talking about defects, saying that he'd be disappointed if Bruce hit a "show-stopper" right off the bat. We need to be documenting the defects in our code as we move it from our private development to the team CVS archive. Bill wants to see the defects coming in as we're working on the code; adding too much at once rasies the risk. Again, we use PRS to log defects after we add or check-in something to CVS. With the first release, we need to be able to discuss the known defects (at the presentation), and we'll have to decide as a team if each defect is a show-stopper or not. We'll also have to gauge the risks of fixing something right now (will more defects be introduced?) The final topics brought up at the meeting included the release notes, which should include the known issues, a feature set, and what's not included in the product. (We should be clear with what might happen when the tool is run.) If we have a good handle on this first release, the next releases will be easier. Lastly, by next week, Bill and Bruce should have a good feeling that we'll have something to deliver.