Minutes-07-March-08 Summit

Attendees

• Paul
• Jimmy
• Hubert
• Jagmit
• Martin
• John Todd
• Bill Muldoon
• Srinivas
• Rich Vasconi
• Sheldon Lee Loy
• Don Ebright
• Ruth
• David Whiteman
• Jack Devine

---

Minutes

Process Discussion

Priority vs. Severity

The problem we are working on is that "enhancement" is a severity field. Therefore, severity can't be used as a way to declare the priority of the work for enhancements.

The solution is that for Defects, we will use the priority and severity fields.

For enhancements, we will use priority only.

The dependency management between Bugzilla entries will remain a project management feature.

Enhancement verification

We discussed having an independent verification of enhancements at end of iteration.

We first discussed a developer doing ad hoc testing of other developers' work. This proposal was rejected due to overhead.

We finally settled on having developers present/demo the enhancements they implemented (along with relevant use cases and documentation changes) to their subproject teams. When a developer completes an enhancement, they mark it fixed. The subproject team then decides whether the enhancement should be verified. We decided this would happen on the first day of the test phase.

For i10, we decided we would do this on a pilot basis, having one enhancement presented for each subproject. The volunteers for this pilot are:

• DV: Bill Muldoon
• DC: Hubert Leung
• RM: David Whiteman

Milestone process

The discussion was whether the milestone exit criteria should be more stringent than the iteration exit criteria.

Does a milestone need to exhibit significantly more function than an iteration? We said that a milestone is a cumulation of several iterations.

Ruth suggested that code reviews would be desirable as part of checking in fixes after a candidate build. There was general concern about implementing more widespread code reviews. David suggested perhaps taking a few classes per subproject to do that, given the numerous methodologies that tout their benefits, but there was still not agreement to the benefit of taking the time to do that on our project, vs. fixing more defects in advance of the 1.0 release.

Release process

For release candidate build, we decided want our code to be "clean". Any APIs that should be deprecated should really be removed, to reduce support implications. Also, anything that might change should be marked provisional. We reviewed the TPTP API Contract page, and agreed this contract is desirable for our project as well. Ruth will investigate the statute of limitations on support for Eclipse projects. We also need to ensure copyrights are in place. It would be nice if developers could also run the TPTP analysis tool to at least identify problem spots (not necessarily adopting all the recommended changes).

Ruth also suggested a "clean code" week in i11. If during that week a developer wishes to remove anything, they have to review that change with COSMOS developers/committers to ensure that they're not breaking anyone else.

Design reviews

All minor design review discussion will be captured by the enhancement authors. We handled the discussion on a per-developer basis.

Ali

There was no significant discussion for the SML 1.1 work, other than 3 weeks remain to complete it.

There was no consensus on enhancement 218313, so Ali will schedule an offline meeting to resolve those design issues.

Joel

Joel was not present on the call, so Don will try to locate designs from him for our review.

Bill

After much discussion, it was agreed that Aperi APIs would be used for ER 209987.

ER 217303 had no significant comments.

Hubert

Hubert discussed the importance of these three ERs, especially from IBM's perspective. All are considered P1 or P2.

Sheldon

Feature page we were using for this agenda is not up to date, so he pointed us to the Arch Call minutes to discuss his designs.

There is a lot of discussion of 214153 as to whether previous query results should be cached. We decided that for now, previous results would not be cached when the query is selected. The sentiment was that we will spin off a separate ER to keep a history of previous query results so cached results can be displayed without the performance hit. There was also discussion that a future ER would be for users to be able to create their own saved queries on the fly, since these canned queries are built at development time.