Cosmos Architecture Meeting 03-December-08

Att: Jason Mark David Brad Mark Jimmy Ruth

3.1 Does this mean that any Figure 2 needs to be reviewed by the Project Lead? Needs to be done under the supervision.

• need to make extra-clear the distinction between an iteration and a milestone. Define why milestones are even more extra-special than iteration. Can an iteration be adopted? A milestone can be. Yes, an iteration can be adopted. Try to have important drivers included in a milestone driver. In a milestone driver, we try to do some of the more finished product kind of things, e.g. string separation, extra level of QA.
• consult with Eclipse to see if they describe Milestones somewhere. They probably have a distinction between a Milestone and an iteration.
• Milestones we allow a buffer in which we are stabilizing the deliverable. No enhancements in the iteration before a milestone release.
• a milestone corresponds to the end of an iteration. Aggregation of multiple iterations.
• In the Identify and accept requirements section add a bullet to say that we collect all enhancement and significant bugzillas to be done in that iteration in a centralised plan, linked from the release plan
• Used to come up with that iteration plan in the Summit.

• Arch lead advises when a design needs to change. Has to be pretty severe before Arch Lead would veto. Litmus test was simplicity.
• Each subteam needs to be aware that when something is large in scope, need to be diligent about bringing those to Mark's attention. Not everything needs to be surfaced that way, but 3rd party dependencies should always be discussed
• Stuff like the APIs, Arch lead leaves that to the team
• anything major, i.e., spanning iterations or dependency on 3rd party, should be raised in the arch lead.
• deep technical conversations held at the architecture call

• write a Milestone Exit Criteria

• need to check our build test reports because the automated JUnits were not being run but they needed to be
• With TPTP tests, they take longer but they produce test reports
• dev't responsibility to run the ones that were not on the UA responsibility page
• idea all automated excepting perhaps the UI tests

• Build team to run the tests on the weekly integration driver as long as there's no QA team
• do not run the weekly integration tests the week before the test pass of the iteration

• combine the two milestone sections in this document to explain the difference between a milestone and a release

• for release candidate build, project leads to approve fixes going in
• clarify what a GOOD build is. any weekly integration build that has all of the function that we need and no major defects. in a community call, each project lead votes which build will be classified as a GOOD build.

• Jason to discuss the reconciliation taxonomy with David off-line. To have that discussion, going to need either John Arwe or Mark Johnson. Perhaps cover next week? Looking at some needs in SDD related topology and being able to define valid host and hosted by releationships and being able to model that. To be able to do that properly, need the concept of a hierarchy, which implies inheritance. Right now taxonomy is flat. Even just to model inheritance in our runtime is complex.
• David encourages Jason to write that in bugzilla, put that against RM, add them to the cc list and we can have the discussion there
• if we can't add inheritance to the reconciliation taxonomy itself, is there a defined process where a person can extend the reconciliation taxonomy?
• next week's meeting we'll have the background bugzilla and discuss the rest live
• doc with reconciliation taxonomy mentions that inheritance may need to be added, so don't think that it will be a surprise
• make these as self-contained as possible
• may still be a way to solve your problem without inheritance