Latest revision as of 08:40, 6 August 2008

COSMOS iteration i12 plan

Cross component work items (Jimmy Mohsin, Sheldon Lee-Loy, David Whiteman, Jason Losh)

externalization/internationalization

• how do we make sure that we keep our strings externalized? automate as part of the build? There's an ER for the build to call a utility that checks for embedded strings. Does it work for both Eclipse UI and Web UI? 220261

security

• few use cases that Paul updated recently. But for i12 we've done as much as we can do. For future iterations we need to do some planning.

logging

• there may be new log records created during i12. There were some log entries that don't conform to the naming convention and as a result the message ids were not assigned to those messages.
• SDD was looking at how to resolve their logging with the rest of COSMOS.
• message IDs to be generated
• We need a checklist for things that need to be done at the end of every iteration. For logging at least there's at least one item that needs to be done at the end of every iteration.
• Ruth to create a wiki page for the checklist; subproject leads to go over this checklist in their next meeting; community to review the final checklist at the next Community call
• Hubert created a wiki page that has a list of all of the log messages that we have. [http://wiki.eclipse.org/COSMOS_Log_Messages}

clean API

• everything done
• there's a build script to confirm that all of our packages confirm to the naming packages? Yes, Leonard did that.
• Javadoc? Public or provisional that we expect people to build on top of needs javadoc. Add "write javadoc" to the checklist.
• Plus generate it with the build. 236501

Design doc every enhancement?

• some don't have design docs because they're such small amount of work.
• design doc to tell someone else how to implement it
• design doc so that the community knows and agrees with the change
• may be useful to put at least in paragraph form and a link to the use case. QA and documentation people will need it too so they know what to test and what to write about.

Mandatory for releasing V0.9 (Ruth Lee)

Review itself

• arrange for COSMOS to be added to the Eclipse Board docket 5 weeks in advance of the intended release of V0.9
• Review slides: Zip of first draft of PPT During the release review we have to explain the divergences from the original plan, such as the addition of SDD.
• answer Harm's question in the review slides: How do the parts of COSMOS relate to each other? If they're disjoint then maybe that's fine and COSMOS can deliver them in disjoint packages. If they're all comingled technically then they should be packaged together. During the mini-project review (version 0.9), we want to state this and to address this question.

Legal

• about.html for third party OSS in COSMOS: Ruth to arrange for these specialized about.html to be written and then delivered to the build team for inclusion in COSMOS
• documentation of COSMOS IP
• get DOJO and other ipzillas approved by Eclipse Legal: list of IPZillas awaiting approval

COSMOS process

• clean up the inactive committer list (done)

Other bullets necessary for a release

June 2008 options

Bugzillas for i12 (Jimmy, Sheldon, David, Jason, Saurabh, Srinivas)

Sizing legend:

• Low - takes 1-3 days
• Medium - takes a week
• High - takes more than a week

Status to be filled in by:

• Data Collection bugzilla status (Jimmy Mohsin)
• Data Visualization bugzilla status (Sheldon Lee-Loy)
• Resource Modeling bugzilla status (David Whiteman)
• Management Enablement bugzilla status (Jason Losh)
• RE/Build bugzilla status (Saurabh Dravid)
• QA bugzilla status (Srinivas Reddy Doma)

The Status column can have one of these values:

• COMPLETE
• On track
• At risk
• Not containable
• Defer (no longer a priority for i12)
• Not started