| [eclipse.org-planning-council] DRAFT Minutes for comments |
Planning Council members,Thanks for the productive meeting last week here in (now sunny) Portland. I attach the draft minutes for your review before I post them on the website. Let me know if you have any comments, corrections, additions, clarifications, quantifications, humor, and even facts to add.
-- *Bjorn Freeman-Benson*Technical Director, Open Source Process and Infrastructure <http://eclipse-projects.blogspot.com/>
Eclipse Foundation <http://www.eclipse.org/>voice: 971-327-7323 (PDT, UTC-7 <http://www.timeanddate.com/worldclock/custom.html?cities=202,188,195>) email: bjorn.freeman-benson@xxxxxxxxxxx <mailto:bjorn.freeman-benson@xxxxxxxxxxx>
Title: Eclipse Planning Council Minutes
May 19, 2005, Portland, Oregon
| Present | Regrets | ||
Paul Clenahan, Actuate |
Georg Lenz, SAP Mike Milinkovich, Eclipse Mike Norman, Scapa Technology James Saliba, Computer Associates Tyler Thessin, Intel Tim Wagner, BEA |
John Graham, Sybase |
|
(these notes are in logical rather than chronological order)
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.
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.
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.
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.
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.
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