We agreed that it would be worthwhile to hold a meeting on July 3 despite the US holiday on Wednesday. We agreed to discuss Jimmy's document which describes the alignment between the COSMOS data collection framework and the CA MR2 project on next week's call.
The group discussed the recent test pass and resulting bugs. One minor bug was raised against the data collection component just after the close of the test pass. We also discussed the need to have better documentation and processes in place prior to starting the first test pass of the next iteration.
We discussed how to organize the planning of our next few milestones. We anticipate that this discussion will expose some feature requirements. Joel and Jimmy agreed to open feature requests for some of the known requirements. We identified a need for refinement of our documentation and agreed to make that a major focus of the next milestone.
Jimmy asked how the QA process is aligned between open source components and commercial products that consume them. Don attempted to explain the division of QA efforts between a typical Eclipse project and its commercial adopters. The project performs its test pass cycles to assure that the project code meets its quality requirements prior to each release. A commercial adopter performs their internal QA processes on their product and when they discover issues within the code of the Eclipse project, they open a bugzilla and work with the project to resolve the issue and get the fix integrated into the next release.
Paul asked how a commercial adopter can get fixes for Eclipse code to their customers in a timely fashion. Hubert explained how IBM works with customer issues in open source code, and Don added a few other comments on the subject. The normal process is to resolve the issue within the Eclipse project and distribute a subsequent point release of the project containing the fix to the customer. In some cases, a commercial product group may independently develop a patch for the Eclipse component and attach it to the Bugzilla entry or even distribute a patched version of the Eclipse code themselves, but the normal process is to align the release of commercial deliverables to coincide with a point release of the open source components that has been tested to function properly in the required use cases. The project needs to be responsive to the needs of its adopters, so priority is given to resolving bugs that impact commercial products and their customers and point releases are scheduled frequently to permit the timely delivery of patches.
Joel suggested discussion of cross component requirements issues on the architecture call. One area in particular that we need to address is coordination of the metadata issues among the subprojects. At present, a number of supposedly opaque objects are exchanged between modeling, data collection, and data reporting, but the goal of isolating the intercomponent dependencies has not been entirely achieved.
Action Items
Joel and Jimmy to open feature requests for input to the planning process.
All to collaborate on improving the wiki pages regarding data collection configuration and testing before the end of the next test pass.
