CS 481 - Team 49 Meeting Minutes Initial Customer Meeting Thursday, September 6, 2007 10:00 - 10:45 am, 1:00 - 2:00 pm JEB 326 Recorder: Brandon Riggers -------------------------------- Meeting Summary This was the second customer meeting that involved our sponsor, Bruce Mayes, who joined the team (us) in person once Thursday morning, and again later in the afternoon. Our discussion with Bruce was very valuable: we asked questions, communicated our own understanding of the project, and laid out and considered our development options for the project. We got a feel for what Bruce is looking for, and what he thinks we'll need to do in the coming weeks (and ultimately, all semester). We also briefly discussed scheduling and the project Concept Proposal. Attendees Brandon Riggers, Shruti Upadhyaya, Peter Brown-Hayes, Travis Thoroman, Bruce Mayes, Bill Junk Topics Discussed Bruce began the discussion by stating that the end goal is to measure turmoil in two ways: on the basis of the files in a ROM image, and on the basis of individual turmoil introduced when files are checked in. Bruce's priority is the run_turmoil tool because it provides a good measure (or idea) of the developers' efficiency. The discussion moved to the development options we could adopt for the project, and the actions we will need to take in order to make the best decision about these options. Bruce mentioned that the "build process will radically change," and that the comparison between the current measure of turmoil and what we'll create has to correlate. Bruce then talked (initially) about the three ways to go about creating our tool (development options): 1. Move the tools to Windows, run them on Cygwin 2. Create tools that are closely related to Subversion 3. Create tools that are more dependent on Subversion (We moved back to discussion of these options, including consideration of the pros and cons of each, during the second hour of the meeting.) In order to know which path to take in creating our project, we will have to do some research and investigation. Bruce talked several times about the need to discover the differences in the 'diff' commands - Linux diff vs. Cygwin diff vs. SVN diff - and also mentioned doing some web research and using these tools on a mock set of files. Our code tool itself may not be all that big - with the possible removal or non-dependence on Clearcase and the TurmoilBetweenLabels file - but we will be doing more research and our tool will have to correlate with the turmoil history in place. How builds are done was another topic of discussion. Bruce briefly explained the current build process - which is recursive and generates a makefile on-the-fly while running through directories - and informed us that under Windows, this build method goes away with the introduction of Windows make tools. Bruce confirmed that he will get us a build list. We then talked about languages, and Bruce said his preference is portability. Perl was brought up, and eventually seemed like a likely choice. Bruce then talked a little more about research, stating that "in the end it comes down to a judgment call" with which option we take with the project. He also mentioned how it was important for quick turnaround when reporting recently introduced turmoil back to a developer. Travis then asked about output and temporary files. Bruce explained that a file list was broken up into what to use, and what to ignore, and that these three lists of files need to be retained. Bruce also added that HTML output files are no longer necessary. One of the things our team will do is contribute to the investigation of the development options and help make a decision. Bill joined the meeting at about 10:30 and briefly discussed scheduling and the Concept Proposal. Our Proposal need to at least consist of a strategy of how to decide which path to take. We'll also need to pin down tentative release dates, and the Beta will need to come before Thanksgiving. When the discussion shifted back to the tools, Bill mentioned that our investigation should involve large-scale tests, and Bruce mentioned how our tool can have a place in it like: "insert your build list here." It was also mentioned that we understand the difference between Subversion change sets and versions. The meeting at 1:00 pm started with Bruce bringing up the issue of the ability (in Subversion) to compare any version of any single file as opposed to just entire directories. This issue and the comparison of the 'diff's make up our main questions about Subversion. We then revisited our three development options and considered some of the pros and cons of each: 1. Port using Cygwin Pros - Faster "time to market" - The tools are already tested (and established) Cons - Requires Cygwin - Requires rewriting more code to replace or remove the 'Clearcase-isms' 2. Migrate UNIX functionality to SVN (using SVN diff) Pros - Fits with Subversion - Possibility of putting it to the public domain Cons - Unknowns, including: - How does it work? - Historical comparison (norming of data) 3. Have SVN report change sets - There is more to know about how this behaves -> investigation Pros - Metrics already generated(?) Cons - Can we strip comments? - Do we know enough to strip comments? Other questions or issues that spur action on our part include Perl interpreters on Windows, the 'diff' comparison, other languages (preferably interpreted), and the measurement base. Bill joined at about 1:30 and talked about our Concept Proposal in more detail. He said we needed to have as many of the investigations mentioned above done or in progress as we can by the time we give the Proposal. He also mentioned the need for a use case in the Proposal, and explained that we need to understand the operation of the tool from a user's view. Can we measure turmoil on the entire project or individual tags or files? Can we preserve file size and deal with the introduction (new existence) of files across sets? We'll also have to understand what turmoil is. Bill talked about how we'll need to give a best estimate of our approach, and a summary of our understanding. We'll need to identify a road map of how to get from today to Thanksgiving. We can back up and try something else if we run into problems - given that this happens within reason.