Revision as of 12:25, 4 June 2008

COSMOS iteration i12 plan

Cross component work items (Mark Weitzel)

externalization/internationalization

security

logging

clean API

release items

Data Collection work items (Jimmy Mohsin)

Themes

• Consumability - remove impediments to adoption
• Stability - reduce the bug backlog
• Quality - refactor as necessary to meet Eclipse API and coding conventions

Large work items

• API standards compliance and other code refactoring
• Security design

Enhancements to consider

Consumability - remove impediments to adoption

Data Visualization work items (Sheldon Lee-Loy)

Themes

• Stability - bugs that will improve the stability of the driver
• Cleanup -bugs that will help meet 1.0 release guidelines and help cleanup code
• Improve Usability - bugs that will improve existing tooling usabillity
• Improve Tooling - enhancements that will provide additional tooling to manage visualize and query MDRs
• Framework Improvements - bugs that will improve the core ui framework

Large work items

• Bugs and ERs are given a rough sizing
  • Low - takes 1-3 days
  • Medium - takes a week
  • High - takes more than a week

Improve Usability - bugs that will improve existing tooling usabillity

Improve Tooling - enhancements that will provide additional tooling to manage visualize and query MDRs

Framework Improvements - bugs that will improve the core ui framework

Resource Modeling work items (David Whiteman)

Themes

• Stability - reduce defect backlog in validator/import/export/editor
• Completeness - expanding tests to cover more nuances from spec, and fixing defects uncovered by this activity
• Documentation - integrate tooling with online documentation using contextual help

Large work items

• API Cleanup

Bugs/ERs to consider

Sizing legend:

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

JUnit test failures:

Spec completeness:

Stability:

Code cleanup:

Management Enablement work items (Jason Losh)

Themes

• Consumability - producing a toolkit that significantly improves the speed & reduces the learning curve with building MDRs
• Design - finalize SDD runtime design
• Initial contributions - commit IBM/SAS code as foundation for tooling/runtime implementation
• Stability - driving out bugs and fixing them
• Testing - improving JUnits to build automated test to connect to and query MDRs built from the toolkit
• Globalization - externalizing all error messages & UI labels
• Documentation - integrate tooling with online documentation using contextual help

Large work items

• Logging
• API Cleanup (bug 229962)
• SDD runtime design finalization
• SDD runtime orchestrator
• SDD build time generator (BTG) framework

Bugs/ERs to consider

Sizing legend:

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

Consumability:

SDD Work:

Testing:

RE/Build team work items (Saurabh Dravid)

Themes

For example:

• Stability
• Globalization
• Accessibility

Large work items

For example:

• Security
• Logging

Enhancements to consider

QA work items (Srinivas Reddy Doma)

Themes

For example:

• Stability
• Globalization
• Accessibility

Large work items

• • http://wiki.eclipse.org/COSMOS_QA_i12_Activities
  • http://wiki.eclipse.org/COSMOS_QA_End2End_Tests

Enhancements to consider

Web/Documentation work items (Rich Vasconi)

Themes

• Consumability
• Documentation

Enhancements to consider

User's Guide and Development Guide Documentation Status for i11

Future Document Enhancements

Mandatory for graduation (Ruth Lee/Tania Makins)

We had a meeting with Bjorn and another meeting with Harm to cover the known questions. Before I get into those answers, generally speaking there are few inviolates. As long as you have a story you can, for example, release an English-only COSMOS even though there is an Eclipse pervasive theme of globalization.

It boils down to what the COSMOS adopters need. Whatever the adopters need we should provide and any discussions about those requirements need to be done in the open in order to be open and transparent to Eclipse.

Bjorn recommended the following:

• That we release a version 0.5 before we release a 1.0 to give us practice going through a release review before the Big Release Review.
• The we clean up our inactive committer list.

Mandatory for graduation:

• Legal (about.html, IP log, all IP Zillas approved, etc.)
  • I am concerned that we don't have permission from Eclipse Legal to use DOJO yet. For details read https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2026. (For those of you who can't read it because you aren't committers, the quote is,
    "Because we identified license and pedigree concerns in the previous version, further investigation is required before we can determine whether the code can be checked into CVS/SVN. We will not be able to grant parallel IP at this time, however we will keep you informed of our progress.
    
    Auto-Generated Text: This submission is now awaiting analysis." I (Ruth) believe that Parallel IP also includes prereqs, but have not yet checked with Eclipse Legal to confirm.
  • We need to open an IPZilla for our prereq of BIRT. (This is as per an email sent to Sheldon and myself responding to my question asking same.)
  • Any changes, such as changing a prereq to a redistribute, changing a version number, using something from Orbit, etc. cannot be done silently or directly to the build team. Please check with Mark Weitzel for an architectural review first, and then he'll tell you the next steps to take. (Note that Bjorn did not tell us this item: this came out of a variety of sources, including a meeting with our mentor who suggested that before a legal review is done that an architectural review is necessary, and that every adopter of COSMOS should be consulted to ensure that the 3rd party open source will not inhibit their adoption of COSMOS due to either legal or technical reasons.)

The questions that we asked Bjorn:

1. How much public API do we need to release?
2. What support will we be required to provide?
3. How many adopters do we need? How do we need to demonstrate adoption?
4. How should we handle the changes to the project roadmap? For example, at Project creation time, SDD was not explicitly in plan.
5. When COSMOS graduates into a Mature project, what project should it graduate into?

Bjorn's answers:

1. (Mark, please correct me if I misstate this.) It depends on what your adopters need. As long as you can demonstrate adoption, then you can release using provisional API if your adopters are happy with that.
2. Whatever you, as a project, decide to do. The only requirement is that you make that guarantee/claim in public as part of the release. (Harm commented that we should consult the adopters to see what they need.)
3. Three would be wonderful, two would be good, one would be ok/iffy (because then it looks like a single company project), zero would be bad. It is okay to demonstrate adoption without the mailing list or newsgroup; that is, public questions/comments on those venues are not required.
4. During your 0.5 Release Review explain the new roadmap & project structure.
5. It's a myth that it has to leave Technology. You can do so if you wish, and if you do then typically projects move to Tools. (Note that Harm recommended the Technology project instead of the Tools project.)

Harm commented:

1. 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.5), we want to state this and to address this question.
2. When releasing a 1.0, that implies that you need to maintain the API until a 2.0 release. He recommended that we use package provisional on any code where the specification has not finalized because if the specification changes significantly then we will be forced to break API out of cycle, and that's bad.