Eclipse Planning Council Minutes

May 19, 2005, Portland, Oregon

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 eclipse.org infrastructure. For example, eclipse.org/services 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:

• Always using the latest milestone, better yet the latest integration, builds of all the underlying projects.
• Provide distributed smoke tests so that the community is not dependent on the project teams to test the integration compatibility.
• John W or Kevin H (Platform) will host train phone calls starting after the Platform defines its release schedule. The Platform expects to commit to a 3.2 schedule before the August council meetings.
• The projects will allow formally announce their opt-in status on their websites and possibly on some sort of more global release train status page.
• Other commitments to be announced.

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:

• What is the version lineup that works on the last major train?
• What is the version lineup that works on the current HEAD train?
• The project leaders section was vague and will be clarified.
• The shipping releases section should be automatically gathered.
• The project description should be taken from the website automatically.
• The executive summary paragraphs are the most important.
• Dependency information
• Perhaps include a list of the third-party libraries and code that is included in the release.
• One page maximum on the printer - the goal is to be able to print out a sheaf of these and read through them on an airplane trip.

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 Eclipse.org 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