| <?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 Planning Council Minutes</h1> |
| <p>June 29, 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>Release Reviews</h3> |
| <p>All Callisto projects (except TPTP, which has already provided these) will |
| send their official release review slides and IP logs to Bjorn for archiving. |
| The official release review slides are the ones based on the <a href="http://www.eclipse.org/projects/dev_process/release-review.php">release |
| review checklist</a>.</p> |
| <h3>Callisto Dot Releases</h3> |
| <p>The Callisto projects would like to coordinate dot releases. The Platform dot |
| releases are generally in September and January. On August 15th (or the nearest |
| Friday) the PC will have a conference call to coordinate towards a dot release |
| RC around September 15th. The goal is to have a dot release on September 29th |
| and somewhere around the end of January.</p> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: [Bjorn FB] arrange dot |
| release conference calls</p> |
| <p>The policy for the dot release is that this is a separate stream for bug |
| fixes only - a branch - no new features; no API changes, additions, or |
| deletions; no major UI changes. Tim explained the WTP policy: the default answer |
| for new features is NO; exceptions are allowed by the PMC, but it's very rare, |
| done in a controlled way, and includes using the cross-project mailing list.</p> |
| <p>We will use the same update site, adding the new jars and versions while |
| keeping the old jars and versions so that both are available at all times. Note |
| that all projects will continue to use their own existing update site - the |
| Callisto update site will remain a pointer to the other update sites.</p> |
| <h3>Retrospective of the Callisto Simultaneous Release</h3> |
| <p>We believe that Callisto was a good model for the way the Eclipse community |
| should/does operate. Callisto put forth two issues: (1) coordination of the |
| builds and (2) common distribution of the results. (1) was motivated by |
| providing value to the Eclipse members (the framework adopters). (2) was what |
| the <i>free tools</i> users wanted. (2) was also motivated by making it easy for |
| the projects to test the combined build.</p> |
| <p>One thing we should do next time is publish a page of all the download links |
| to the respective projects' downloads in case someone did not want to (or was |
| unable to) use the update manager.</p> |
| <p>An issue that we believe we did poorly on was integrated testing. Most |
| project teams tested with the whole stack installed, but did not test other |
| projects' features. "We lived down to our low expectations." DTP |
| should be singled out for having contributed testers to the overall testing - |
| not just to DTP. The projects did not find a lot of Callisto-centric bugs, |
| although there were a number of packaging/releasing type bugs that were found by |
| the outside community.</p> |
| <p>The Great Bugs Contest was thought to be a good idea, but we did not end up |
| with much integration testing anyway. Thus perhaps the contest did not succeed.</p> |
| <p>Another issue that caused a lot of confusion amongst both ourselves and our |
| consumers was the difference between <i>run-time</i> and <i>SDK</i>. We should |
| be clearer what each entails for Europa.</p> |
| <p>The team conference calls generally worked. It is best to set them as far in |
| advance as possible. Once a month at first. Once a week during the RCs.</p> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: [Bjorn FB] schedule the |
| first few conference calls</p> |
| <p>Coordinating around the milestones was harder than some predicted. There was |
| confusion around the lag times and especially if I wanted to test six days into |
| the milestone, which set of versions did I need to get? There was also confusion |
| about when the projects were going to commit to the milestone dates.</p> |
| <p>There was not uniform agreement on what it meant to be a "Release |
| Candidate". There were quality issues (projects had different quality |
| standards) and there were naming issues (Callisto RC3 was not the same as |
| Platform RC3). We should define more clearly what we expect from each release |
| candidate, i.e., the level of quality, the ramp down policy in effect, etc. We |
| should also consider calling the Europa RCs something other than "RC".</p> |
| <p>For the Europa coordinated release, we must be clear on the rules for |
| participating and we should make those rules be <b>must</b>, <b>should</b>, and <b>recommended</b>. |
| We should make as few <b>must</b> rules as possible and all the rules should be |
| agreed upon by the team. Each rule should explain why we are adopting (or |
| suggesting) this rule - not just the rule, but the reason as well. We need to |
| acknowledge that kicking projects off the release train for not conforming is a |
| very big step and is probably unrealistic; thus we need to commit to each other |
| to cooperate anyway.</p> |
| <p>One of our issues on Callisto was the decision making process. Some decisions |
| were made in the absence of some of the projects. Not all project |
| representatives can attend all the meetings, and yet we still need a decision |
| making process that works in spite of that. We also need some sort of email or |
| official record of the votes. And we need <i>technical soak</i> time for bigger |
| decisions - it is unrealistic to expect snap decisions on big issues.</p> |
| <h3>Europa</h3> |
| <p>The Platform project is planning similar milestones and dates as last year. |
| The Platform will publish those dates by the end of July and everyone else is |
| fine with following the Platform's lead on the dates.</p> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: [Kevin H] publish the |
| milestone dates to the mailing list</p> |
| <p>The projects are aiming for an end-of-September synchronization on milestones |
| and builds. We definitely have to be synchronized and cooperating by |
| December/January.</p> |
| <p>We discussed the criteria for joining the Europa train. We agreed that one of |
| the rules needs to about attending the planning meetings and conference calls - |
| you have to be involved to be involved. And projects need to have build process |
| maturity and a self-sufficient update site. We discussed the idea of mentoring |
| new projects or writing a guide, but nobody was willing to commit to the time |
| needed. We discussed how late one might be able to join the release train; |
| perhaps: until Christmas = probably fine; until EclipseCon = need a good |
| argument; after that = impossible.</p> |
| <p>There was a discussion of which JVM to use for Europa. Because running Europa |
| will require running with the highest level JVM of all the plug-ins, running all |
| of Europa is almost certainly going to need JVM 1.5.</p> |
| <p>What's the real objective of Europa? Simultaneous release or cross-project |
| compatibility? Callisto but with more projects and less arguing. We noted that |
| giving it a name (Europa) sets high expectations. Fortunately, those high |
| expectations from the community cause the community to help us make them work |
| together better. Enables projects to have discussions about deeper level |
| integration. With each yearly release the projects are getting better: quality, |
| features, interop - but this is not the focus - the focus remains on |
| simultaneous release.</p> |
| <p>We agreed that we need more finely tuned fourth field version number. We |
| should all agree on what it means.</p> |
| <p>Discussion about run-time, SDK, end user docs, api docs, isv docs, etc. There |
| was no general agreement other than that an SDK contains additional stuff that |
| is needed to build with the platform but does not need to ship with the platform |
| run-time. We discussed the question of whether the SDK should be available via |
| the Europa update site.</p> |
| <p>David noted that we should be consistent around product/primary feature |
| plug-ins.</p> |
| <p>Bjorn will create a wiki page to describe and discuss the Europa rules (must, |
| should, recommend) and that this group will aim to decide on the rules by T-1 |
| month, where T is the date of the first synchronization milestone.</p> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: [Bjorn FB] create the wiki |
| page</p> |
| <p>More potential rules: i. other people should be able to build your project; |
| ii. other people should be able to run your unit tests; iii. NL enablement and |
| translations; iv. Callisto-style bugzilla bucket (it worked well, we should |
| continue)</p> |
| <p>One of our big challenges with the release train (Callisto and Europa), is |
| that we have projects with different maturity levels and how can we |
| convey/explain that to the consumers (users and adopters). We did not come to a |
| good conclusion other that being part of the train means cooperating with the |
| entire set of train projects.</p> |
| <h3>Standard Charter</h3> |
| <p>We discussed Tyler's suggested changes to the Standard Charter v1.0. We liked |
| them all except 9 and 11. The concern on 11 was the idea that in open source |
| projects the committers are in charge not some central authority, even if that |
| authority is the PMC. We also touched on that the whole charter/top-level |
| project/sub-project/component thing is ambiguous at times. A larger effort would |
| be required to rewrite all this into a Europa-like must, should, recommend style |
| charter.</p> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: [Bjorn FB] create a |
| Standard Charter v1.1</p> |
| <h3>IP Process Requirements</h3> |
| <p>The Planning Council has these requirements for the Eclipse IP Process:</p> |
| <ul> |
| <li>Transparency, especially of the status of a contribution questionnaire and |
| its position on the queue</li> |
| <li>People should be able to run IP clearance in parallel with development. |
| Perhaps a shadow repository. Or allow code to be checked in before it is |
| reviewed, but just not released before it is reviewed. The goal is to |
| prevent the legal review delay (no matter how short it is) from slowing down |
| development. |
| <ul> |
| <li>Checkin-but-not-release seems like a good idea to us. What if we find |
| that there is an IP violation? Do we need to remove the code from CVS? |
| What happens now? Have we gone back and removed offending code in the |
| past? How would that be different here?</li> |
| </ul> |
| </li> |
| <li>Project leads and PMCs need to be cc'd on CQs and replies. The status of |
| CQs needs to be visible to submitters, project leads, and PMCs.</li> |
| <li>Self service tools for scanning by PMCs and PLs (and committers).</li> |
| <li>Foundation-sponsored training for committers around IP responsibilities</li> |
| <li>Earlier in the cycle for reviewing about.html files and such. Aim for |
| milestone M-n approval and "no new third-party stuff added after |
| Mx"</li> |
| <li>legal@ should reply to emails in a timely manner</li> |
| <li>It takes too friggin' long. |
| <ul> |
| <li>Perhaps we can have quick provisional approvals.</li> |
| </ul> |
| </li> |
| </ul> |
| <p><font color="#800080"><u><b>ACTION</b></u></font>: [Bjorn FB] pass these |
| along to legal@</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); |
| ?> |