COSMOS/COSMOS iteration i12 plan

COSMOS iteration i12 plan

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

Bug	Severity	Description	Owner	Sizing
216332	Enhancement	Complete design for COSMOS Security - phase 2	Jimmy	Medium

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

Bug	Severity	Description	Owner	Sizing
222709 (new)	normal	QueryBuilder should populate the MdrID	sleeloy@ca.ibm.com	Low
224169 (Need to upgrade to Dojo 1.1)	enhancement	Ability to resize dialog box.	martin.simmonds@ca.com	Medium
223241 (Need to upgrade to Dojo 1.1)	enhancement	Full screen mode toolbar button	sleeloy@ca.ibm.com	Medium
229083 (future?)	enhancement	Predefined queries with parameters	sleeloy@ca.ibm.com	Low

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

Bug	Severity	Description	Owner	Sizing
230405 (future?)	Create a Report based on CMDBf information	sleeloy@ca.ibm.com	Medium
222504 (future?)	enhancement	UI cannot show the query request	sleeloy@ca.ibm.com	Medium
211093 (future?)	enhancement	Custom visualization for example MDR	sleeloy@ca.ibm.com	Medium

Framework Improvements - bugs that will improve the core ui framework

Bug	Severity	Description	Owner	Sizing
229411 (legal?)	enhancement	Upgrade to Dojo 1.1	sleeloy@ca.ibm.com	Medium-High

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:

Bug #	Severity	Owner	Description	Sizing
228223	major	Ali Mehregani	Data center sample validation errors - TestPluginMainValidator failures	Low-Medium
200423	normal	Dlwhiteman.us.ibm.com	JUnit test TestSMLModelUnits.testRuleInvalidBinding failure	Low

Spec completeness:

Bug #	Severity	Owner	Description	Sizing
229890	major	Ali Mehregani	Locating SML documents remotely	Low

Stability:

Bug #	Severity	Owner	Description	Sizing
221409	major	Dlwhiteman.us.ibm.com	Identifying definition content type fails when WTP is installed	Low
185391	major	Dlwhiteman.us.ibm.com	Export SMLIF wizard > ruleBindings page shows no documents	Low

Code cleanup:

Bug #	Severity	Owner	Description	Sizing
218814	normal	Ali Mehregani	Reduce dependencies for SML MDR	Low

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:

Bug #	Severity	Description	Owner	Sizing
216332	enhancement	Complete design for COSMOS Security - phase 2	Jimmy Mohsin	High
220594	enhancement	Provide contextual help for toolkit UI	Dlwhiteman.us.ibm.com	Low

SDD Work:

Bug	Severity	Description	Owner	Sizing
229088	enhancement	Create initial SDD runtime framework for COSMOS installation	Jason Losh	High

Testing:

Bug #	Severity	Description	Owner	Sizing
230282	enhancement	Create JUnit test for running & querying projects built from toolkit	Dlwhiteman.us.ibm.com	Medium

RE/Build team work items (Saurabh Dravid)

Themes

For example:

• Stability
• Globalization
• Accessibility

Large work items

For example:

• Security
• Logging

Enhancements to consider

Enhancement	Severity	Description	Blocked by (if applicable)	Owner	Sizing
215609	Normal	Maintain documentation of third party dependencies		Ruth Lee	Low
215135	Enhancement	Establish a process for running JUnits against a COSMOS build		Bobby Joseph	High
229078	Blocker	Add about.html and other legal files to the build		Ruth Lee	Medium

QA work items (Srinivas Reddy Doma)

Themes

For example:

• Stability
• Globalization
• Accessibility

Large work items

For example:

• Security
• Logging

Enhancements to consider

Bug#	Severity	Description	Owner	Sizing
232764	enhancement	Document i11 QA activites	domsr01@ca.com	Low
233436	enhancement	Define and document COSMOS QA End2End Test cases	domsr01@ca.com	Low

Web/Documentation work items (Rich Vasconi)

Themes

• Consumability
• Documentation

Enhancements to consider

Consumability:

Bug #	Severity	Owner	Description	Sizing
202332	major	Ali Mehregani	Need a viewlet version of the COSMOS demo	Low
225817	normal	Mark Weitzel	New overview of COSMOS needed on web site	Low

Documentation plan:

Enhancement	Severity	Owner	Description	Sizing
216655	enhancement	vasconi@us.ibm.com	Include Javadoc in online Eclipse help	Low
218825	enhancement	vasconi@us.ibm.com	COSMOS User's Guide development	Med
218828	enhancement	weitzelm@us.ibm.com	COSMOS User's Guide Overview development	?
218830	enhancement	weitzelm@us.ibm.com	Write COSMOS User's Guide Prerequisites	?
218849	enhancement	william.muldoon@ca.com	Write Introduction to CMDBf section for COSMOS User's Guide	?
219117	enhancement	jason.losh@sas.com	Write Solution Deployment Descriptor (SDD) section for COSOMS User's Guide	?
219120	enhancement	hkyleung@ca.ibm.com	Write Running the Example section for the COSMOS User's Guide	?
219138	enhancement	weitzelm@us.ibm.com	Write Overview section for COSMOS Development Guide	?
219141	enhancement	hkyleung@ca.ibm.com	Write Constructing a Data Manager section in COSMOS Development Guide	?
219142	enhancement	amehrega@ca.ibm.com	Write Providing CMDBf Query and Registration Services section in COSMOS Development Guide	3 days
219143	enhancement	sleeloy@ca.ibm.com	Write Extending the Web User Interface Framework section in COSMOS Development Guide	?
219148	enhancement	bsubram@us.ibm.com	Write the WSDM Tooling section in COSMOS Development Guide	?
219156	enhancement	jim@gyng.com	Write COSMOS Installation Guide	?

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.