Eclipse Planning Council Minutes

May 19, 2005, Portland, Oregon

Present      Regrets

Paul Clenahan, Actuate
John Duimovich, IBM Corporation   
Bjorn Freeman-Benson, Eclipse
Doug Gaff, Wind River
Richard Gronback, Borland
Kevin Haaland, IBM Corporation

Georg Lenz, SAP
Mike Milinkovich, Eclipse
Mike Norman, Scapa Technology
James Saliba, Computer Associates
Tyler Thessin, Intel
Tim Wagner, BEA

John Graham, Sybase

Minutes / Discussion Items

(these notes are in logical rather than chronological order)

Participation In Reviews

We discussed the Eclipse Quality issues that the other councils had discussed the previous two days. There are not many notes on this as the issues had been discussed at some length previously. The only item of note was that the idea of proposals should have Champions was brought up and discussed - no definitive conclusion was reached.

IP Policy

Tim Wager (WTP) brought up the concern that the EMO was not keeping up with the IP reviews and that because WTP was only one milestone away from release 0.7, there does not appear to be enough time to complete the reviews. Mike explained that this is a temporary problem of the EMO dealing with the backlog of needing to re-review all the contributions to date. Mike expects the EMO to be caught up to real-time by the end of 2005. In the meantime, bring any looming deadlines to Mike's attention.

Project Infrastructure at the Foundation

A number of the projects had asked for virtual servers at the Foundation, but it turns out there are technical problems that prevent that from working easily. And the Foundation's rack does not have enough space to host inexpensive 1U servers for each project. The temporary solution is for top-level projects to host their extra services elsewhere and use redirects to appear to be part of the infrastructure. For example, is hosted off-site.

Planning, Information, and Synchronized Releases

The Requirements Council has expressed a requirement that the major projects have synchronized releases; where synchronized means "ship on the same day". The Requirements Council did not want to require synchronized version numbers because that would eliminate the semantic meaning of version numbers. There is a need to communicate which version of each project works with which other version both upstream and downstream.  The upstream compatibility is handled automatically by the Update Manager, although it would be nice to have a documentation version of that same information.  But the downstream compatibility is not described - if I have version X of project Y, what version of project Q can I successful use?

We agreed that synchronized releases would be driven by the Platform releases - a "release train", if you will - and that there would be one train per year. Projects may release more often of course, but should have a release that joins the train as well. A project that is having internal trouble synchronizing can opt-out and ship later, but if the same project is having troubles due to an underlying train framework (such as something in Platform) will cause the whole train to slip its release.

All of this is opt-in, but the expectation is that all the major projects will opt-in. Opting-in is a significant commitment by the projects and it includes:

ACTION: Kevin H will come to the August Planning Council meeting with the mechanics of what projects are opting-in to; and at the August meeting the project will opt-in or not.

Status Report Format

We discussed the .dates.txt prototype that Bjorn had put together and decided to switch to an XML file. The XML file will take the place of the static HTML quarterly status executive summaries. This file will have all the current summary information as well as:

ACTION: Bjorn FB will write some tools that process these XML status reports: collate them for the website; build the timeline of releases; send reminders to project leaders who have not updated their status; etc.

Website Content

We discussed who the website has a lot of woefully out-of-date, and perhaps even wrong, pages lying around. We agreed that we need to have either good information or no information, but we cannot tolerate bad data.

ACTION: Everyone agreed to freshen their content, either by (the best choice) making it good or (second choice) removing all the obsolete and incorrect pages. Everyone agreed to do so by one month after the Platform 3.1 release ships, if not before.

Notes taken and posted by Bjorn Freeman-Benson