| <html> |
| |
| <head> |
| <link rel="stylesheet" href="http://www.eclipse.org/default_style.css"> |
| <meta http-equiv="Content-Language" content="en-us"> |
| <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> |
| <meta name="GENERATOR" content="Microsoft FrontPage 4.0"> |
| <meta name="ProgId" content="FrontPage.Editor.Document"> |
| <title>Eclipse Planning Council Minutes</title> |
| </head> |
| |
| <body> |
| |
| <h1>Eclipse Planning Council Minutes</h1> |
| <p>May 19, 2005, Portland, Oregon</p> |
| <table border="0"> |
| <tr> |
| <td valign="top" colspan="2" align="center" bgcolor="#CCCCCC"><b>Present</b></td> |
| <td valign="top" align="center"><b> </b></td> |
| <td valign="top" align="center" bgcolor="#CCCCCC"><b>Regrets</b></td> |
| </tr> |
| <tr> |
| <td valign="top"><p> |
| Paul Clenahan, Actuate<br> |
| John Duimovich, IBM Corporation <br> |
| Bjorn Freeman-Benson, Eclipse<br> |
| Doug Gaff, Wind River<br> |
| Richard Gronback, Borland<br> |
| Kevin Haaland, IBM Corporation<br> |
| </td> |
| <td valign="top"> |
| Georg Lenz, SAP<br> |
| Mike Milinkovich, Eclipse<br> |
| Mike Norman, Scapa Technology<br> |
| James Saliba, Computer Associates<br> |
| Tyler Thessin, Intel<br> |
| Tim Wagner, BEA</td> |
| <td valign="top"></td> |
| <td valign="top"><p>John Graham, Sybase</td> |
| </tr> |
| </table> |
| <h2>Minutes / Discussion Items</h2> |
| <p><i> (these notes are in logical rather than |
| chronological order)</i></p> |
| <h3>Participation In Reviews</h3> |
| <p>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.</p> |
| <h3>IP Policy</h3> |
| <p>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.</p> |
| <h3>Project Infrastructure at the Foundation</h3> |
| <p align="left">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, <a href="http://www.eclipse.org/services/">eclipse.org/services</a> |
| is hosted off-site.</p> |
| <h3>Planning, Information, and Synchronized Releases</h3> |
| <p>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?</p> |
| <p>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.</p> |
| <p>All of this is <i>opt-in</i>, but the expectation is that all the major |
| projects will opt-in. Opting-in is a significant commitment by the projects and |
| it includes:</p> |
| <ul> |
| <li>Always using the latest milestone, better yet the latest integration, |
| builds of all the underlying projects.</li> |
| <li>Provide distributed smoke tests so that the community is not dependent on |
| the project teams to test the integration compatibility.</li> |
| <li>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.</li> |
| <li>The projects will allow formally announce their opt-in status on their |
| websites and possibly on some sort of more global <i>release train status</i> |
| page.</li> |
| <li>Other commitments to be announced.</li> |
| </ul> |
| <p><font color="#800080"><u><b>ACTION</b>:</u></font> 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.</p> |
| <h3>Status Report Format</h3> |
| <p>We discussed the <code><a href="http://www.eclipse.org/org/processes/master-timeline.php">.dates.txt</a></code> |
| 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:</p> |
| <ul> |
| <li>What is the version lineup that works on the last major train?</li> |
| <li>What is the version lineup that works on the current HEAD train?</li> |
| <li>The project leaders section was vague and will be clarified.</li> |
| <li>The shipping releases section should be automatically gathered.</li> |
| <li>The project description should be taken from the website automatically.</li> |
| <li>The executive summary paragraphs are the most important.</li> |
| <li>Dependency information</li> |
| <li>Perhaps include a list of the third-party libraries and code that is |
| included in the release.</li> |
| <li>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.</li> |
| </ul> |
| <p><font color="#800080"><u><b>ACTION:</b></u></font> 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.</p> |
| <h3>Website Content</h3> |
| <p>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.</p> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: 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.</p> |
| <p><i>Notes taken and posted by Bjorn Freeman-Benson</i></p> |
| |
| </body> |
| |
| </html> |
