Skip to main content

Eclipse Planning Council Minutes

January 23, 2007, Burlingame, California

Note that the attendance list is not accurate at this time.

Present      Regrets
Sri Doddapaneni, Intel, TPTP Doug Schaefer, QNX, Tools
Bjorn Freeman-Benson, Eclipse Doug Gaff, Wind River, DSDP
John Graham, Sybase, DTP Tim Wagner, BEA, WTP
Rich Gronback, Borland
Kevin Haaland, IBM, Platform
Yossi Leon, Zend
Wenfeng Li, Actuate, BIRT
Ed Merks, IBM, Modeling
Paul Styles, Compuware
Jess ?, BEA
David Williams, IBM
Oisin Hurley, IONA, STP

Minutes / Discussion Items

Europa CQ Prioritization Process

Discussion of the Europa CQ prioritization process as defined by Janet [1]. The Council members felt that the Legal queue was long and getting longer and were nervous that this trend is going the wrong way. In general the Council felt that the deadline of January 31st for submitting new material was reasonable, but they would like the deadline for submitting incremental requests (updated versions of previous approved third-party libraries) to be later. The reason is to be able to include the latest and greatest versions of, say, Apache libraries even if they are released (by, e.g., Apache) even if they are released late in the Europa release cycle. While it would be convenient if the entire software world revolved around the Eclipse yearly releases, it doesn't, so our processes need to accommodate that. Bjorn explained how  much work is required even for incremental releases (a lot) and the Council members decided that they could live with an M6 date for the deadline for CQs for incrementals. Project teams will assist with incrementals by providing diff reports on what has changed at all levels of nesting.

The projects also agreed to (pending a checklist/example) submit a complete list of all nested jars and source code so that Janet's team can start the examination with less leg work.

ACTION: [Bjorn FB] Take these requests to Eclipse Legal:

  • New third-party libraries deadline  is January 31st
  • Incremental third-party libraries deadline is RC0 (May 4)

ACTION: [Bjorn FB] Take these suggestions to Eclipse Legal:

  • Transparency: publish a probability distribution of how long (calendar time) it takes to process CQs
  • Process: publish a checklist of things that projects should be looking for and trying to solve before submitting CQs: license issues, code scanning, etc.
  • Ease of Use: a better Contribution Questionnaire - many of the projects find the existing one confusing, the sections and questions hard to understand, and there are no examples of how to fill it out
  • SLA: Service Level Agreements for short contributions having quick response times

Ed Merks also requested that IPZilla be opened to contributors as well as a committers so that the committers do not have to act as intermediaries when trying to resolve issues between committers and Eclipse Legal.

Europa Schedule and Rules Review

We reviewed the schedule and rules on the Europa wiki page. We revised the rules a bit (on the wiki page). Also: BIRT will help WTP and TPTP move their common shared jars to Orbit. And we promoted "written ramp down policy" from should do to must do.

The ramp down policy should include: named milestones (API freeze, feature complete, RC0), rules for what it takes to get a change in (team says want to fix, , consensus has to review and approve all changes; the process we use to say no); definition of what "RC" means to each project; etc.

ACTION: [all] All Europa projects will have a written ramp down policy on their website and in the wiki by February 23rd.

We also discussed changing the name of RCs to Europa Candidates (ECs) to accommodate the varying quality of the projects. 

JVM 1.4 versus JVM 5

TPTP has worked around the issue raised earlier by having the TPTP stand-alone run-time use EMF 2.2.

ACTION: [Ed M] Add a link to the Europa page to his wiki page discussing the EMF 2.2/2.3 features and JVM 1.4/1.5 issues and what the consequences of whether one should use EMF 2.2 or 2.3 - here is the link

Additionally, the group consensus was to label your own plug-ins with the minimum run-time for that plug-in and not to consider the minimum run-times of dependencies. Be sure to test your code against both the 1.4 and 5 JVMs.

Using Non-APIs

After must discussion, we concluded that:

  • Projects SHOULD NOT use non-APIs from other projects, but if you must then...
  • When using non-APIs, projects MUST have opened bugzillas against the other projects and include references to those bugzillas in the release notes and the release review slides. Projects MUST also have a plan for addressing the non-API issue in their next major release.
  • When using non-APIs, projects MUST NOT expose those consumed non-APIs through the project's own APIs. We cannot even begin to explain what a bad idea that would be.
  • When using non-APIs, projects MUST participate in the same maintenance releases as the projects they are using from.

Finding the right balance of progress versus risk is very difficult thus our goal is to expose the risk of the use of non-APIs. We even considered having a clown-nose icon that is attached to a project's website should they use non-APIs.

Europa SDKs and Run-times

The main issue here is that "SDK" means different things for different projects. In the end we concluded that there are at least three different things: (1) run-time, (2) tooling, (3) extender kit. Not all projects have all three. The run-time is like the VM for the project - consider the EMF run-time: there's no tooling and it is just what is needed to execute an EMF model. However, the Platform run-time distro does include tooling: the basic Eclipse IDE tools. (Hence confusion over the wording)

The tooling distro of a project includes the run-time (to run the tools), end user tools, and end user documentation. The extender kit for each project is the tooling disto plus that which is required to extend the underlying frameworks. Also known as an SDK, the extender contains source code, adopter documentation, examples, etc. We decided that the extended kit SHOULD include an explanation (in the help system) of how to get the examples for the project although the examples do not necessarily have to be included with the kit. This is often useful because the examples should be installed the developer's workspace instead of in the Eclipse instance itself and the Eclipse distro mechanism can only install to the instance.

The Council decided that each Europa project will have two entries in the feature list: an "end-user" feature and an "extender" feature. The Council further decided that each project will distribute it's pure run-time separately from the main Europa update site. Here we are taking the position that the Europa update site is for end-users and not as a substitute for the project-specific download pages for project-specific things (such as project-specific run-times/VMs).

ACTION: [all] Update the wiki page to explain whether your project will include examples as part of the extender version.

ACTION: [all] Update your project's features to include the words "end-user" and "extender".

Support for Previous Releases

After much discussion around support, what it means, and the potential for an unreasonable burden on the volunteers who work on the open source projects, we concluded that:

  1. Projects are expected to follow the open source development model for their current major release, and
  2. Projects are expected to help educate their communities on what the open source development model is, and what it means for support. The fundamental thing it means for support is that projects are not supported in the same way that commercial projects are supported - the community is expected to participate in the support if the community wants to benefit from the support.

We concluded that projects participating in the annual release are effectively signing up for the two related maintenance releases as well (although there is no requirement for new bits for the maintenance releases as long as the old bits continue to work).

User Interface Working Group

Bob Fraser gave a report on the User Interface Working Group. Bob asks that the Planning Council promote the existence of the working group to their project teams. The working group is making a push now to affect the M5 and M6 releases of the projects for the Europa time-frame, and then a bigger push for next year's Ganymede release.

ACTION: [all] Explain the User Interface Working Group to your project teams (project dev lists?)

ACTION: [Bjorn FB] get the slides from Bob to attach to this web page.

Europa Build Software

Bjorn gives a short report: not done yet. "Soon," he promises. "Before M5?," someone asks. "Yes"

Internationalization of Eclipse Projects

For years IBM has provided translations of the Eclipse Platform. IBM has decided not to do this alone anymore. IBM will contribute resources to the internationalization effort, but will not lead nor provide a majority of the resources for Europa. Thus, unless the Planning Council steps up to do plan and execute the translations, the Europa projects will not be translated. Period.

Paul Colton showed us Aptana's wiki-like solution for translations. This was very cool and we all jumped on the idea at once as being a great way for the community to participate. There was some concern from the corporate members that the quality would not be sufficient for them, so the one twist we thought of was to have any bugzilla account able to contribute (just like a patch) but have committers (language committers) give the final approval for inclusion in the builds (just like a patch). Or at least to enable this on a language-by-language basis. Paul offered the software to the Eclipse Foundation.

The Council feels that there are four options for translations:

  1. (today's default) no translations; English only; companies will do their own proprietary translations
  2. Aptana tool for any bugzilla login; Europa download for users will have random quality translations; companies will do their own proprietary translations
  3. Aptana tool for any bugzilla login with committer review-apply; Europa translations will be fairly good
  4. An Eclipse Translations project with project leadership and full-time resources

Our goal should be to follow the open source principles as much as possible with respect to translations - to be open and transparent and to involve the larger community.

ACTION: [Bjorn FB] Work with Paul to see how we can incorporate Aptana's software or something similar for projects to use.

The Council decided to follow up on translations in two parts: (1) ask their (mostly corporate) framework users which translations are necessary; and (2) reporting the incremental number of strings that will need translation for Europa for their specific project. (Not all the strings in the project, just those that are new or have changed.)

ACTION ITEM: [all] Report to Bjorn by Monday the 29th the incremental number of strings in your project.

Report From the Orbit Project

David Williams reports that there are fifteen (15) bundles and there is a build process that produces zips. Currently projects that consume Orbit bundles must download the zips and incorporate them in their own update sites. Rich Gronback counter argues that Orbit should produce an update site, if only for the automated builds, and then the builds can just get everthing they need via the update site.

ACTION: [Rich G] Enter a bugzilla to request that the Orbit project include an update site for automated builds to consume. - bug 171955

Roadmap Contribution

The Planning Council Roadmap contribution is the frozen-in-time aggregation of all the Europa projects' plans.

ACTION: [all] Make sure your project plan is available on your website. Enter the url to your plan in wiki. These are due by Feb 2nd in order to be incorporated into the Roadmap.

Conforming Project Websites

Bjorn explained the Board's resolution about websites and explained his experience to date with convincing Technology projects to conform. He further explained his nag-o-matic software as the next level of convincing projects to conform and promised to extend this effort to all projects over the course of the next six months.

Some projects' responses to this were "hmm, I think I'll talk to my Board rep to get this policy changed" :-)

Testing and Testing Frameworks

Tim Wagner was not able to attend so Jess attempted to explain Tim's ideas. After discussion, we concluded three things:

  1. We need to carefully distinguish between supported configurations (for testing) and unsupported configurations. If it is a supported configuration and someone tests it and finds a bug, there is an implied agreement that the project will fix that bug. Kevin Haaland says that to do otherwise would be violating a trust.
  2. We should use the Open Source Way as much as possible for tests. We like the CPAN scheme of having a community driven testing grid. Projects can specify which platforms are of interest, and of course the definition of platform varies by project: for example, the PDE platforms include operating systems and JVMs while the WTP platforms include web servers.
  3. We should avoid having a centralized rack of servers/configurations and emphasize having a community-participation testing effort.

Committer-Centric Workshop Ideas

The Planning Council declares that a workshop around the update manager would be a good thing. The build workshop was successful because the problem required a cross-project solution. The update manager isn't quite the same because it doesn't require a cross-project solution, but it is needed by all the projects thus many are eager to help. 

This workshop will be for people who are intending to become committers on the update component. This will not be a requirements gathering event - this is an event for doers: people committed to being committers.

The Planning Council recommends that July-August would be the best time frame for this effort: after Europa, but early enough in Ganymede to make a difference.

ACTION: [Bjorn FB] pass these ideas along to Ward

Europa Release Review

The Europa Release Review will be Wednesday, June 6th, 7am Pacific time. The release review slide decks (the whole deck with all the checklist items) are due by May 30th.

ACTION ITEM: [all] Mark your calendars

Future Simultaneous Releases

We chose "Ganymede" for the 2008 release and "Io" for the 2009 release.

Notes taken and posted by Bjorn Freeman-Benson

Back to the top