councils/20060629PCMinutes.php

<?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>&nbsp;&nbsp;&nbsp;&nbsp;</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. &quot;We lived down to our low expectations.&quot; 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 &quot;Release
Candidate&quot;. 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 &quot;RC&quot;.</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 &quot;no new third-party stuff added after
    Mx&quot;</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);
?>