CS 481 - Team 49 Meeting Minutes Weekly Team Meeting Friday, September 28, 2007 10:30 - 11:30 AM JEB 324 Recorder: Shruti Upadhyaya -------------------------------- Attendees: Bill Junk, Bruce Mayes (over the phone), Brandon Riggers, Travis Thoromon, Peter Brown-Hayes, Shruti Upadhyaya Different options we talked about: * We will have to go either with Perl diff or Cygwin. * We have might to use comment stripper outside of svn diff. * Use Subversion as data repository. * Use our own comment stripper. * We are still not sure which diff utility to pick * We might have to go with Windows diff, but there are many versions of Windows diff. Bruce recommend picking a diff utility which is more “Linux-like.” * We have made our current design simple enough that we can easily change diff utility later and not make a big change in our project. * Subversion allows us to use external diff utility. Therefore, if we can find an independent diff utility, we can just plug it in with our current project. * Even though we are changing the diff utility, we are not changing the date of our first release. * We need to correlate the old metric with the new metrics and estimate the scaling factor by the end of the semester. Documentation: Bruce would like to see a summary of three alternatives of diff utility and the reasons why the other two don’t work in our Design Specification. All the test specifications should be in bullet form. Release pack should include the code, documentation, test files, set of release notes. The set of release notes should include open defects of delivery, symptoms, and consequences. Testing: We need to send complicated outputs to test Metrics Engine effectively. Status of Cygwin: Bruce mentioned that they might already have Cygwin installed in all the machines at HP. Therefore, one of the possibilities might be using Cygwin. Presentation: We have changed the date of Presentation of our 1st release on Monday (Oct 8th) at 10:30, so that Bruce can join us over the phone. We will upload our 1st release in the webpage and send an email to Bruce and Bill in tarball as well as zip files. Bill mentioned a few things we need to do before our 1st release. By Monday or Tuesday, we need to code-freeze all the code functionality that the 1st release is supposed to have. By code-freeze, it means we should not add any additional features after this date. If we do think we need to add more features, it needs to be a different branch of the code. The defects that we discover before and after the code-freeze need to be logged into PRS. Three Buckets: Categories: The defects that are “showstoppers” are the ones that limit Bruce to work. Those defects need to be fixed. We need to modify the code and rerun the whole test suite. Modifying and writing the code has side defects. We need follow the test strategies that is mentioned in the following link – http://www2.cs.uidaho.edu/~cs481/ProjectEndGame.html Trivial changes: If we have user interface error, a graphical error, or document error, or anything that has to do with making the project look good, do not fix. The reason is the risk of causing errors. We need to determine how significant is the defect vs. the risk that we might inherit by modifying the code. High Priority: Fix defects, run the test aggressively and expect certain behavior. We need to run test suite one at a time. At the end, run the full test suite and expect certain behavior. Presentation: The guidelines are listed in the website. We need to briefly include the motivation of the project, current design of the project, performance information, and a plot of code activities. A plot of code activities is a volume of code changes overtime in CVS, information on how many tests were run, how many tests passes, and the characteristics of the code that didn’t pass. Overall, we need to be able to convince that it is a good release. In our next release, we need to have defects in time-block plots. Our last slide should include what is coming for our next release.