Friends of Eclipse,
Eclipse is an open source community that benefits millions of developers around the world each and every day! During the month of September, we are asking you to give back to our wonderful open source community. All donations will be used to improve Eclipse technology. Your contribution counts!
We thank you for this gesture, and for giving back to our community.
January 23, 2007, Burlingame, California
Note that the attendance list is not accurate at this time.
|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|
Discussion of the Europa CQ prioritization process as defined by Janet . 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:
ACTION: [Bjorn FB] Take these suggestions to Eclipse Legal:
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.
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.
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.
After must discussion, we concluded that:
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.
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".
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:
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).
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.
Bjorn gives a short report: not done yet. "Soon," he promises. "Before M5?," someone asks. "Yes"
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:
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.
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
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.
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" :-)
Tim Wagner was not able to attend so Jess attempted to explain Tim's ideas. After discussion, we concluded three things:
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
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
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