| <?php require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); $App = new App(); $Nav = new Nav(); $Menu = new Menu(); include($App->getProjectCommon()); # All on the same line to unclutter the user's desktop' |
| |
| $pageTitle = "June 2006 Planning Council Minutes"; |
| $pageKeywords = "planning council minutes"; |
| $pageAuthor = "Bjorn Freeman-Benson Aug 06"; |
| |
| ob_start(); |
| ?> |
| <div id="maincontent"> |
| <div id="midcolumn"> |
| <h1> Eclipse Architecture Council Minutes</h1> |
| <p>June 28, Chicago, Illinois</p> |
| <table border="0"> |
| <tbody><tr> |
| <td align="center" bgcolor="#cccccc" valign="top"><b>Present</b></td> |
| <td align="center" valign="top"><b> </b></td> |
| <td align="center" bgcolor="#cccccc" valign="top"><b>Regrets</b></td> |
| </tr> |
| <tr> |
| <td valign="top" align="center"><i>no data</i></td> |
| <td valign="top" align="center"></td> |
| <td valign="top" align="center"><i>no data</i></td> |
| </tr> |
| </tbody></table> |
| <h2>Minutes / Discussion Items</h2> |
| <p><i> (these notes are in logical rather than |
| chronological order)</i></p> |
| <h3>JVM Issue</h3> |
| <p>Discussion about what JVM version will be required/supported by Europa. Some |
| of the points included: is Eclipse going to be a 1.4 application and not move to |
| 1.5? Perhaps the statement is that "Eclipse is a framework built around |
| 1.4"? How do we respond to "you are no longer cool because you are |
| stuck on 1.4"? (if we choose that) The problem is, of course, that 1.5 is |
| really a new language (but 1.6 is not).</p> |
| <p>Projects should tell their dependencies what the project's JVM requirements |
| are so that the dependent projects can either concur or push back. The Platform |
| will continue to run on JVM 1.4 but if you run on 1.5 you will get additional |
| features. Moving to 1.5 is not mandatory; execution can move; new plug-ins can |
| move to 1.5 features. Our goal is to have both a smaller 1.4 version and to |
| support all the new features of 1.5 - i.e., the best of both worlds. Our goal is |
| no gratuitous 1.5 - go ahead and use 1.5 where necessary. Document it. Specify |
| it in the manifest file.</p> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: [Ed Merks, Michael Scharf] |
| draft the initial wiki page describing the implications of changing to |
| 1.5. </p> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: [All] All projects should |
| have a statement in their project plan about their position on 1.5. </p> |
| <h3>Multi-Core</h3> |
| <p>We briefly discussed the fact that the Architecture Council should provide |
| guidelines for developers about multi-core-safe and then |
| multi-core-utilizing programs. </p> |
| <h3>Common Build Infrastructure</h3> |
| <p>We discussed build infrastructure and the question of why are all the |
| projects doing our own specialized build systems and scripts? This makes |
| coordination hard. For example, version number ranges - Ed explained why he |
| doesn't want to do it manually. He has a script that computes it as part of his |
| builder. People should use a common build infrastructure, but we should probably |
| not require it. We should require certain interface/API characteristics, such as |
| an RSS feed. Some projects (such as BIRT) find the RSS to be a low priority |
| because they build on a schedule rather than no notification.</p> |
| <p>Reasons for a common build infrastructure:</p> |
| <ul> |
| <li>Automation</li> |
| <li>To get it right</li> |
| <li>Go to someone else's project and build it </li> |
| </ul> |
| <p>Kevin says "any automation for this stuff is good". <br> |
| We don't want to force too much conformity because that stops innovation; |
| alternately, conformity in the base allows innovation higher up. Another |
| argument is that innovation at the build system should not be being done. </p> |
| <p>We should have a build teams get-together for social, technical, and |
| requirements gathering. Ward offered that the Portland Eclipse team would be |
| happy to arrange/host that. This gathering should be assembled with some sort of |
| direction - what would that be? AC members should gather the problems their |
| build teams are having, and the features their build systems have: "Pain |
| and Pride". Optionally a wishlist. </p> |
| <p>We had a goal of doing this by July 20 but because the minutes were not |
| published until September, that didn't happen. </p> |
| <p>We also discussed common shaped (directories and files) build results? |
| Perhaps our common build system can also have some evaluation tools (such as |
| checking for overlapping third-party library versions) that could help with |
| Europa. This proposal is about Europa build support, not about the Eclipse |
| Foundation common build system for small/all projects. If the Eclipse Foundation |
| wanted to offer that feature, it would have to supply its own |
| people/machines/resources and release engineers to help.</p> |
| <h3>Eclipse Commons</h3> |
| <p>Jeff describes <a href="http://www.eclipse.org/proposals/orbit/">his proposal</a>. |
| Also a best practices recommendations. We got side-tracked a bit on the legal |
| issues of whether each project would need to get legal approval to depend on the |
| commons plug-ins and if so, whether it could get approval for version * instead |
| of version 1.6 (e.g.). We went off in another direction for a while on the |
| granularity of features versus plug-ins versus update manager. This is |
| definitely topic for the next council meeting. </p> |
| <p>Questions (and some answers):</p> |
| <ul> |
| <li>Why do this Commons project? To expose and control dependencies. </li> |
| <li>How would we deal with the source of these things? </li> |
| <li>For third-party only or for sharing common bits of Eclipse as well? Let's |
| start with third-party only. We can evolve it over time and to start with |
| this. "Commons" is not quite the right name; something about |
| "Third-Party" might be better. </li> |
| </ul> |
| <p>When polled, the room was all positive. Jeff volunteered as the project lead. |
| All the teams that contribute third-party bundles would have committers on the |
| project.</p> |
| <p><i>Notes taken and posted by Bjorn Freeman-Benson</i></p> |
| </div> |
| </div> |
| <?php |
| $html = ob_get_contents(); |
| ob_end_clean(); |
| |
| # Generate the web page |
| $App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html); |
| ?> |