| <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>August 23, 2005, Boston, Massachusetts</p> |
| <table border="0"> |
| <tbody><tr> |
| <td colspan="2" 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"><p> |
| Paula Cox, IBM (visitor)<br> |
| Sri Doddapaneni, Intel, TPTP<br> |
| Bjorn Freeman-Benson, Eclipse<br> |
| Doug Gaff, Wind River, DSDP<br> |
| John Graham, Sybase, DTP<br> |
| <br> |
| </p></td> |
| <td valign="top"> |
| Richard Gronback, Borland, GMF<br> |
| Kevin Haaland, IBM, Platform<br> |
| Wenfeng Li, Actuate, BIRT<br> |
| Tim Wagner, BEA, WTP</td> |
| <td valign="top"></td> |
| <td valign="top"><p>John Duimovich, IBM<br> |
| Georg Lenz, SAP (conflict w/ RC)<br> |
| Mike Milinovich, Eclipse (conflict w/ RC)<br> |
| Mike Norman, Scapa (conflict w/ RC)<br> |
| Jim Saliba, CA (conflict w/ RC)</p></td> |
| </tr> |
| </tbody></table> |
| <h2>Minutes / Discussion Items</h2> |
| <p><i> (these notes are in logical rather than |
| chronological order)</i></p> |
| <h3>Action Items from Previous Meetings</h3> |
| <p>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 - <i>completed, |
| see below.</i></p> |
| <p>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. - <i>file format proposed; tools not written; re-promised for |
| 4Q2005; see below.</i></p> |
| <p>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 - <i>a couple projects |
| freshened their content, most did not; re-promised for end of September; see |
| below.</i></p> |
| <h3>Website Content</h3> |
| <p>We re-discussed how 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>: [ALL] 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 re-agreed to do so by |
| the end of September, if not before.</p> |
| <h3>Standard Website Content</h3> |
| <p>At the first Committer Gathering (held in Portland), the committer community |
| suggested that each project home page have "the same four links in the same |
| place with the same names" so that anyone could go to a project page and |
| find the essential project information. Everyone thought this was a good idea |
| and we decided: (a) that the "four links" should be at the top of the |
| left menu bar; (b) that there should be more than four links (see list below); |
| (c) that they should be fly-out menus; and (d) that Bjorn should create some |
| magical PHP include file that does this all in very easy, "takes no effort |
| on the part of the projects", way.</p> |
| <p>There are three audiences for this material: consumers, contributors, and |
| project members. It's hard to choose a set of links that is both useful and |
| compact, but this is what we decided to try:</p> |
| <ul> |
| <li>Home</li> |
| <li>About |
| <ul> |
| <li>Description (and Subprojects)</li> |
| <li>Project plan</li> |
| <li>Leadership & Minutes</li> |
| <li>Committers</li> |
| <li>Community</li> |
| </ul> |
| </li> |
| <li>Downloads</li> |
| <li>Getting Started</li> |
| <li>Development |
| <ul> |
| <li>Development plan</li> |
| <li>Mailing lists</li> |
| <li>CVS</li> |
| <li>Bugs</li> |
| </ul> |
| </li> |
| </ul> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: [Bjorn FB] agreed to |
| create the PHP include script for the menu and Tim W volunteered WTP to be the |
| test project. Doug G volunteered to evaluate the instructions against the goal |
| of "takes no effort on the part of the projects".</p> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: [Bjorn FB] to create a |
| blank template initial project website so that new projects don't have to browse |
| around and copy others.</p> |
| <h3>Release Train</h3> |
| <p>Kevin H described the Platform 3.2 schedule and discussed the modifications |
| that will be necessary for the train. There was a lot of discussion around the |
| train and what it will take to coordinate and release on the same date. The |
| overall summary is that the end game will be extended by an additional milestone |
| and thus API Freeze will be M5 and Feature Complete will be M6/RC0. (Note that |
| the milestone dates in 2006 are in flux and will probably be adjusted to work |
| around EclipseCon.) M2 is September 23rd, M3 is November 4th, and M4 is |
| December 16th. Each project is assigned a "offset" number which is the |
| number of weeks their milestone dates are offset from the Platform dates. Thus |
| BIRT, being a +1 project, has milestone dates of M2 = Sep 30, M3 = Nov 11, M4 = |
| Dec 23, etc. These offsets will (obviously) be reduced over the end-game (e.g. |
| +1 week, +1 half-week, +1 quarter-week, +1 day, +1 hour, etc) until |
| they all reach zero. These offsets are a loose characterization of their |
| dependency on other projects - loose because the dependencies are grouped into |
| three buckets (+0, +1, +2) rather than the five or six that a full dependency |
| list would entail. Five buckets would not work for six week milestones, hence we |
| collapsed it to three buckets.</p> |
| <p>The projects participating in the release train, the milestone they expect to |
| start synchronizing, and the offset are as follows:</p> |
| <ul> |
| <li><a href="http://www.eclipse.org/birt">BIRT</a>, M2 (+2)</li> |
| <li><a href="http://www.eclipse.org/cdt">CDT</a>, not yet confirmed on the train (+1)</li> |
| <li><a href="http://www.eclipse.org/datatools">DTP</a>, M3 (+1)</li> |
| <li><a href="http://www.eclisep.org/emf">EMF</a>, ? (+1)</li> |
| <li><a href="http://www.eclipse.org/gef">GEF</a>, ? (+1)</li> |
| <li><a href="http://www.eclipse.org/gmf">GMF</a>, M3 (+2)</li> |
| <li><a href="http://www.eclipse.org/ve">VE</a>, ? (+1)</li> |
| <li><a href="http://www.eclipse.org/tptp">TPTP</a>, M3 (+2)</li> |
| <li><a href="http://www.eclipse.org/wtp">WTP</a>, M3 (+2)</li> |
| </ul> |
| <p>Note that participation in this initial train is limited - not everyone who |
| wants to join will be able to join this year. Assuming success, the process will |
| be opened to additional projects next year. Also note that if a project falls |
| behind the train schedule, it will be dropped - we will not slip the train. A |
| third note: any project that has not synchronized by M5 is off the train for |
| this year.</p> |
| <p align="left">What does it mean to be "on" or "off" the |
| train? First, any project is welcome to release simultaneously with any other |
| project. The existence of the release train does not prevent, e.g., <a href="/mylar">Mylar</a>, |
| from releasing at the same time as the <a href="/eclipse">Platform</a>. The |
| difference is two-fold: first, the Foundation expects to have some press |
| activities around the train release; projects that are part of the train will |
| get more attention than projects that are not. Second, the projects on the train |
| are committing to help each other achieve the release. Thus bugs submitted by |
| train members will likely get more attention than bugs submitted by non-members.</p> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: [Kevin H and Paula C] will |
| pass this information along to the EMF, GEF, VE and UML2 leads. <i>- Completed |
| 9/11</i></p> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: [Doug G or Bjorn FB] will |
| pass this information along to the CDT leads.</p> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: [Bjorn FB] will work with |
| the Tools PMC and the Executive Director to get the right representation for EMF, |
| GEF, VE, and CDT at the train coordination portion of the December and March |
| Planning Council meetings.</p> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: [Wenfeng L, John G, Tyler |
| T, Tim W, John D] All train projects need to have a project plan.</p> |
| <p align="left"><font color="#800080"><u><b>ACTION</b></u></font>: [Bjorn FB] at |
| <a href="http://www.eclipsecon.org/2006/">EclipseCon</a>, the PC and Eclipse |
| legal will meet to coordinate all the IP reviews and Release Reviews so that |
| there isn't an impossible-to-complete mad rush at the end.</p> |
| <p>FYI The tentative Platform maintenance releases are 3.1.1 end of September |
| and 3.1.2 end of January/February.</p> |
| <h3>Status Reporting Format</h3> |
| <p>Bjorn FB brought forward a <a href="http://www.eclipse.org/org/processes/Guidelines_for_Eclipse_Development_Process/status-and-planning-reporting.html">proposed project status reporting |
| file format</a>. Discussion included: </p> |
| <ul> |
| <li>Is this for top-level projects or sub-projects or both? Conclusion: it |
| depends on the PMC.</li> |
| <li>Need a link to the update site(s) as well as the download link.</li> |
| <li>Nice to link to a URL for the description. Suggest linking to a URL and |
| parsing for a <div id="short description"> to extract a |
| description that gets added to the XML file <description> section.</li> |
| <li>Guidelines for what should be in the executive summary. Note that it is |
| not just a summary of the scope of the project.</li> |
| <li>Add a paragraph of description/status/summary to each upcoming and past |
| releases.</li> |
| <li>Would like to have notifications when other projects' statuses change - |
| email? RSS?</li> |
| <li>Next year we should include release train information so that we can |
| generate a larger release train status document.</li> |
| </ul> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: [Bjorn FB] will update the |
| proposal, publish it, and write the software to parse it.</p> |
| <h3>Roadmap</h3> |
| <p align="left">We discussed the Roadmap process. Last year's <a href="http://www.eclipse.org/org/councils/roadmap.html"> Roadmap 1.0</a> was |
| difficult to put together and we want the process to be easier this year. One |
| question we had for the Council plenary is whether the timing is correct, i.e., |
| should the Roadmap be done in July after the train release and thus be a 12 |
| month planning document, or should we stay with January which makes it a 3 month |
| and 15 month planning document? The project status reporting format (above) will |
| have all the information necessary for the PC contributions to the Roadmap <i>except</i> |
| for the Forward Looking Statement section. We plan to change that section to |
| "Thematic Advancement" and describe how each project is contributing |
| to the Themes and Priorities. In other words, to concrete statements about |
| higher levels features and how they are being worked on. Be sure to refer to |
| which release the feature is going into, especially for projects (like TPTP) |
| that have multiple releases per year.</p> |
| <p>Then we switched to a discussion of how to make the Roadmap a more useful |
| document for the projects. All projects stated that they were using the Themes |
| and Priorities as part of their planning process, but only one part. The key |
| thing that all requirements coming into a project need to have is compelling |
| value to the project team. Requirements also need to be actionable, i.e., have |
| attached Bugzilla entries. It is important to remember that at Eclipse, there is |
| a meritocracy of ideas and thus requirements need to justify themselves.</p> |
| <p>Kevin H pointed out that we all believe that the integrity of the Eclipse |
| brand means something. And this means that all projects have to spend some time |
| working on requirements that are "for Eclipse" rather than just |
| "for the project". Some projects are better at this than others, but |
| all of them need to make sure they spending time on the greater good. (We also |
| have to make sure that when we reject something (such as a Bugzilla WONTFIX), we |
| do so with care because bad news travels quickly.)</p> |
| <p align="left"><font color="#800080"><u><b>ACTION</b></u></font>: [Bjorn FB] will add these |
| words to <a href="http://http://www.eclipse.org/org/processes/Guidelines_for_Eclipse_Development_Process/"> the guidelines</a></p> |
| <h3>Changes to Bugzilla</h3> |
| <p align="left">Wenfeng L brought a set of defect tracking requirements to the Council - |
| difference between Acutate's internal bug tracking system and Bugzilla. Wenfeng |
| entered these as <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106261">bugs 106261</a> and |
| <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106263">106263</a>. After discussion, the |
| bugs were updated with the Councils suggestion that many of the requests are |
| already handled by Bugzilla, but that adding options for enhancements was a good |
| idea.</p> |
| <h3>Project IP Log</h3> |
| <p>Discussion of the newly visible, but has always existed, requirement that all |
| projects keep <a href="http://www.eclipse.org/org/processes/Guidelines_for_Eclipse_Development_Process/project-log.html"> a Project IP |
| Log</a>. The draft guidelines include a |
| description of the log.</p> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: [Bjorn FB] fix the |
| grammar/spelling errors; fix the query explanation to include that Bugzilla |
| needs to record the contributor's name; add that all patches must be submitted |
| through Bugzilla, never by email; </p> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: [Bjorn FB] discuss with |
| Mike M and Janet C the <a href="http://www.eclipse.org/legal/privacy.html"> Eclipse privacy policy</a> versus the Project |
| IP Log; note that if the IP log requires all contributor addresses to be public, |
| that will violate our privacy policy</p> |
| <p>Tim W has entered <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=105636">bug |
| 105636</a> asking for a better tracking scheme for IP forms and approval |
| requests.</p> |
| <p>The Council as a whole requested that Bjorn work with Janet to clarify |
| exactly what the process for code contributions is. For example, can the code be |
| placed in Bugzilla so that it can be looked at? Can the code be used before the |
| "ok to use" answer returns from Eclipse legal? Does the same full |
| process apply to junior developers at the same company but who are not yet |
| committers? There are many scenarios to consider and the Council members would |
| like a step-by-step colored flowchart of the process to follow. For example, |
| "green if you have authored all the code", "yellow path if |
| authored by a junior member of your team and you work for a member |
| company", etc.</p> |
| <ul> |
| <li>Existing corporate IP</li> |
| <li>Developer fixing a large section of code and then patching it back (note: |
| developer, not committer)</li> |
| <li>Developer refactoring existing code and then patching it back</li> |
| <li>Inside the company versus outside the company; inside other strategic |
| members versus non-members</li> |
| <li>Less than 100 LOCs versus greater than 100 LOC</li> |
| <li>Patch to existing function versus adding new function</li> |
| <li>Etc.</li> |
| </ul> |
| <h3>Development Process Guidelines</h3> |
| <p align="left">In general the Council thought the <a href="http://www.eclipse.org/org/processes/Guidelines_for_Eclipse_Development_Process/"> Development Process |
| Guidelines</a> were good, but they felt that the guidelines should be improved in a |
| number of areas:</p> |
| <ul> |
| <li>The <i>required</i> items should be marked differently from the <i>recommended</i> |
| items. The guidelines cover both but it is not clear which is which right |
| now.</li> |
| <li>The Guidelines should be clear that this is the only Foundation document that you |
| need to read - that this document includes all the relevant details from the |
| Development Process. Currently the Guidelines are not comprehensive, but |
| they should be because otherwise it is too much hassle for the developers to |
| figure out what to read. Projects may have additional project-specific |
| documentation augmenting the Guidelines.</li> |
| <li>Make it clear that the enclosing PMC is responsible for the project |
| regardless of the project's phase.</li> |
| <li>The "how to make infrastructure changes" section should be made |
| even simpler, perhaps organized by type of infrastructure</li> |
| </ul> |
| <p>The Council wants to have a good process, but they also want to make sure |
| that we don't set the bar too high or we will never have new projects or new |
| committers.</p> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: [Bjorn FB] make these |
| changes</p> |
| <h3>Other</h3> |
| <p>The Council discussed project mentors. We decided to try a |
| committer-to-committer mentoring program from the experienced (mature) projects |
| to the less experienced (incubation) projects. The goal is to transfer knowledge |
| of all those little things that make being a committer in an Eclipse project |
| easier.</p> |
| <p><font color="#800080"><u><b>ACTION</b></u></font> [Kevin H, Sri D, Tim W] |
| each to provide the names of three mentors. These people will be paired with |
| committers on DSDP, DTP, and GMF.</p> |
| <p>The Council is concerned that email addresses in Bugzilla are showing up on |
| Google and can be viewed by people who don't even have an Eclipse Bugzilla |
| account.</p> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: [Bjorn FB] follow up with |
| Denis on this issue</p> |
| <p><i>Notes taken and posted by Bjorn Freeman-Benson</i></p> |
| |
| </body></html> |
