COSMOS PROPOSAL ITERATION

Proposal for declaring an integration driver

• During the last week of development in the iteration, all code check-ins stop once the candidate weekly integration driver is built. <David>since there is a specific "Friday" and "Monday" mentioned, when does this process start in the last week? Does the release schedule need to change so that iterations always end on the same weekday?</David>
• RE announces the candidate weekly integration driver but CVS is not yet open for new code. COSMOS is in shut-down mode. The JUnits will be run on the candidate weekly driver, the results posted to cosmos-dev, and the results reviewed in the Architecture call as usual.
• During shut-down mode, if a developer wants to check in any changes for the candidate iteration build, that developer must request permission from the Leads (Project, Architecture) before those changes are checked in.
• The developer sends the request for permission to the cosmos-mgmt mailing list. This request identifies the changes to be checked in, why they can't be deferred to a future iteration, and the risk of the change. (Where "risk" means "what could be broken if we allow this change?".) <David>how would the developer see the reply to the permission request, since cosmos-mgmt is only monitored by leads?</David>
• A Lead allows or defers the changes and cc RE so that RE can track the list of bugzillas allowed in. RE maintains a wiki site with a cumulative list of the bugzilla numbers and details provided by the developers.
• On Friday morning at 9:00 AM, RE sends that list of bugzillas and files changed to cosmos-dev and anyone affected by any of the changes checked in during shut-down mode runs the JUnits that test just the affected code. (Don't know if it's possible to separate the JUnits like that, but that's the ideal to reduce the amount of time needed for testing.) Any problems found are fixed ASAP.
• On Monday at 9:00 AM, someone from RE will send a post to cosmos-dev identifying the official integration driver to be used for the testing and stating that CVS is now open.

Ruth's take on the FAQ from i8

• What sort of Defects warrant a new build during the QA phase?
  

<Ruth>Blocking</Ruth>

• If there is a build happening to fix a high priority Defect, can lower priority defect fixes be sneaked in as well?
  

<Ruth>Nothing should be sneaked in. If it's lower priority then why are we working on it? Don't we have enough P1 to work on? The exception to that last statement would be for something minor such as a typo in the UI that is both easy to fix, low risk, and fast to fix. I still say that shouldn't go in because if it's that low priority, then there's no harm in waiting and waiting will keep our records honest. Developers can attach a patch to the bugzilla to be checked in the next iteration.</Ruth>

• What role should a Lead have in a QA phase build?
  

<Ruth>A Lead has two roles: 1. Approving fixes for blocking problems. 2. Voting when a candidate driver should be promoted to the official driver. When all Leads vote +1 (or abstain), and there are no "-1" then the build is promoted to the final official integration driver.</Ruth>

• What metric do we use to define the LAST build during the QA phase to mark the iteration closed? FYI, last time around, there was a lot of confusion in regards to this point and there was a weekend emergency.
  

<Ruth>All tests attempted, no tests blocked, no blocker bugs. For the definition of "blocker" we can use the TPTP definition as a launching-off point: TPTP definition
</Ruth>

For future discussions on Milestone and THE BIG (v1.0) Driver

I think that the following TPTP documents would be a good launching-off point for COSMOS discussions:

• TPTP API Contract
• Stop-ship template