Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

COSMOSMonthlySummit-Apr2008/COSMOSJune2008Options

Options for the COSMOS June 2008 Release

This is my opinion/assessment. Please take it with a grain of salt. A COSMOS Lead needs to review this with an Eclipse person to confirm that this is accurate.

Option 1: Release 1.0 in June, graduate to a Top-Level Project

Option 2: Release 0.x in June, remain an Incubation Project

To achieve this, COSMOS must go through a Release Review. (Why do you say this?) For a Release Review, COSMOS must fulfill all of the details in this document: http://www.eclipse.org/projects/dev_process/release-review.php This is a summary of the questions that COSMOS must answer for just the Requirements, not the Guidelines.

Requirement Summary
2.1 Features Features themselves are in place or will be by the June deliverable.


Looking for opinions on the statement, "Compare the features against the Roadmap to understand the project's conformance or divergence."

  • You can read about the Roadmap Process here: http://www.eclipse.org/org/councils/roadmap_v2_0/index.php#process
  • And you can read about it some more here http://www.eclipse.org/projects/dev_process/development_process.php#5_Roadmap_Process

    The Project Leadership is expected to ensure that their Project Plans are consistent with the Roadmap, and that all plans, technical documents and reports are publicly available. To meet this requirement, each Project is expected to create a transparently available Project Plan in an EMO-defined file format that meets the following criteria:

    1. Enumerates the areas of change in the frameworks and tools for each proposed Release
    2. Consistent with and categorized in terms of the themes and priorities of the Roadmap
    3. Identifies and accommodates cross-project dependencies
    4. Addresses requirements critical to the Ecosystem and/or the Membership at Large
    5. Advances the Project in functionality, quality, and performance

    A Project may incrementally revise their Project Plan to deliver additional tasks provided that:

    1. the approved Roadmap is not put in jeopardy; and
    2. the work is consistent with the Project Plan criteria (as described above)

  • You can read COSMOS's Project Plan here: http://wiki.eclipse.org/COSMOS_Project_Plan (This needs to be updated.)
  • You can read COSMOS Creation Review slides here: http://www.eclipse.org/proposals/cosmos/ (Is COSMOS in sync with the original proposal?)
2.2 Non-code aspects COSMOS is planning to ship some of the documentation in the driver and some on the web. Mark needs to check with Bjorn that this is acceptable. What about the other bullets? What do you think?
2.3 APIs COSMOS needs to certify that its APIs are Eclipse Quality http://www.eclipse.org/projects/dev_process/eclipse-quality.php

This is a big one. Ali has started the process to get the Javadoc in place. Someone needs to take the to-do to check that every subproject has its API conforming to that document. Volunteers?

COSMOS is currently planning to release its June release with provisional APIs only.

  • Mark asked Bjorn, "Can we release COSMOS without any public API? Our intention here is that we would have no API or a very limited set. "
  • Bjorn replied, "...I doubt you will get approval from the community to release COSMOS with no API. Eclipse is about "extensible frameworks" and something with no API is hardly an extensible framework... However, perhaps there's more to the story than just "no API", so maybe you could explain how COSMOS 1.0 will be an extensible framework ?"
  • Mark needs to follow up with Bjorn to clear this up.
2.4 Architectural issues Does COSMOS have any architectural issues?
2.5 Tool usability Explain how we made the tools usable.
2.6 End-of-life No previous release.
2.7 Bugzilla FYI that COSMOS will be asked about the number of defects and enhancements that are pending and how many P1 & P2 etc. are outstanding.
2.7 Standards

(Note that they have two 2.7
bullets; their mistake, not mine.)

Explain the standards that COSMOS is implementing and in what state those standards are.
2.8 UI Usability Summarize COSMOS' conformance to the Eclipse User Interface Guidelines: http://wiki.eclipse.org/index.php/User_Interface_Guidelines
Does COSMOS have anything that does not conform to these guidelines?
2.9 Schedule Did any schedule date slip in COSMOS' history?
2.10 Communities Explain how COSMOS builds its three communities: http://www.eclipse.org/projects/dev_process/development_process.php#2_5_Three_Communities
COSMOS clearly has Contributors and Committers, but what Users and what Adopters does COSMOS have? We need to list them. How does COSMOS demonstrate adoption and what is the Foundation looking for?
2.11 IP Issues We need to get about.html and other legal documentation in place.
We need to get IPZillas opened for every prerequisite that COSMOS depends on as well as anything that COSMOS redistributes.
Did every committer count the number of lines in every contribution to confirm that they fell under the 250 line limit? Because the COSMOS Project Log doesn't list any non-committer contributions today, and that's valid only if every contribution was 250 lines or less. Plus we have to address every other bullet in this section in the Release Review documentation. Not going to list them all here.
2.12 IP Issues speak-up-now Out of our hands. An Eclipse Member may complain that COSMOS infringes on their IP rights.
2.13 Project Plan This one is a guideline, not a requirement. If COSMOS has a draft plan for the next release we need to include it for this review.

Option 3: Release 1.0 in June, graduate to a Mature Project

First, COSMOS needs its two mentors, Harm Sluiman and Valentina Popescu, to vote +1 to pass a Graduation Review (http://www.eclipse.org/projects/dev_process/development_process.php#6_1_Mentors).

To achieve this, COSMOS must go through the Release Review as in Option #2 and also must go through a Graduation Review. (Why do you say this?)

Requirement Summary
The criteria for graduating from Incubation to Mature include:
  • A working and demonstrable code base with extensible frameworks and exemplary tools (see [1]).
  • Active communities (see [2]).
    • An active framework user (plug-in provider) community.
    • An active tool user community.
    • An active multi-organization committer/contributor/developer community.
  • The project is operating fully in the open using open source rules of engagement, e.g.,
    • Open and transparent Bugzilla with a described and documented bug process.
    • Open and transparent project schedules.
    • The project has working policies and procedures for developing, specifying, testing, and getting feedback on APIs.
    • The project decision making processes are published, and all project decisions are being made in public.
  • The project team members have learned the ropes and logistics of being an Eclipse project. In Apache parlance, the project "gets the Eclipse way".
    • Abiding by the base Eclipse Development Process as well as the additional rules defined by the EMO.
    • Adherence to the Eclipse IP Policy including an assesment of how well each Committer is following the committer responsibilities and due diligence rules. It is every Committer's responsibility to learn, know, and follow these rules.
    • Participating in the larger Eclipse community. For example, teaching tutorials at EclipseCon or other conferences, writing articles, participating in the Reviews of other projects, etc.
    • Working with other projects in its enclosing top-level Project.
    • The project is a credit to Eclipse and is functioning well within the Eclipse community.
  • An in-depth review of the technical architecture of the project, and its dependencies and interactions with other projects.

Bullet #1: any issues or questions?

  • Mark needs to follow up with Bjorn on how much public API COSMOS would need to release to be considered an "extensible framework"
Bullet #2: any issues or questions?




Bullet #3: any issues or questions?

  • How does COSMOS get feedback on APIs? Can someone volunteer to verify that everything is documented in here: http://wiki.eclipse.org/COSMOS_dev_process
  • Are all of the processes published? Do the published processes refer to the subproject leads? Some of the leads are not stepping up to do what they were originally intended to do, and in the case of one, he is no longer active in COSMOS at all. The issue is that the Board might say "How can COSMOS be mature when you don't have active leadership?" Do we need to restructure COSMOS before we go through a Graduation review? If we restructure COSMOS, do we need to change the APIs?
Bullet #4: any issues or questions?
  • The Eclipse Development Process: who volunteers to be the point person for driving this verification across COSMOS?
  • Ditto the Eclipse IP Policy?
  • People have attended EclipseCon. What else have people done?
  • COSMOS has worked with Aperi and Higgins, I believe?







Bullet #5: any issues or questions?

Quote from the Guidelines for Incubation Phase

Section: Initial Code and Development, subsection Interim Releases.
http://www.eclipse.org/projects/dev_process/incubation-phase.php
Incubation Phrase projects may make 0.N releases (e.g., 0.2, 0.5, 0.7, ...) but may not release an N.0 or greater releases (e.g., not 1.0, 1.2, 2.0, ...). A project ready to make a 1.0 release is a project ready to graduate from Incubation. All major releases (i.e., 0.N and M.N) releases, must go through a Release Review.

Resources so far

Retrieved from "https://wiki.eclipse.org/index.php?title=COSMOSMonthlySummit-Apr2008/COSMOSJune2008Options&oldid=91681"

This page was last modified 14:02, 10 April 2008 by Ruth Lee.

Back to the top