Skip to main content

Eclipse Planning Council Minutes

June 29, Chicago, Illinois

Present      Regrets
no data no data

Minutes / Discussion Items

(these notes are in logical rather than chronological order)

Release Reviews

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 release review checklist.

Callisto Dot Releases

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.

ACTION: [Bjorn FB] arrange dot release conference calls

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.

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.

Retrospective of the Callisto Simultaneous Release

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 free tools users wanted. (2) was also motivated by making it easy for the projects to test the combined build.

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.

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.

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.

Another issue that caused a lot of confusion amongst both ourselves and our consumers was the difference between run-time and SDK. We should be clearer what each entails for Europa.

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.

ACTION: [Bjorn FB] schedule the first few conference calls

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.

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".

For the Europa coordinated release, we must be clear on the rules for participating and we should make those rules be must, should, and recommended. We should make as few must 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.

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 technical soak time for bigger decisions - it is unrealistic to expect snap decisions on big issues.

Europa

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.

ACTION: [Kevin H] publish the milestone dates to the mailing list

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.

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.

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.

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.

We agreed that we need more finely tuned fourth field version number. We should all agree on what it means.

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.

David noted that we should be consistent around product/primary feature plug-ins.

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.

ACTION: [Bjorn FB] create the wiki page

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)

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.

Standard Charter

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.

ACTION: [Bjorn FB] create a Standard Charter v1.1

IP Process Requirements

The Planning Council has these requirements for the Eclipse IP Process:

  • Transparency, especially of the status of a contribution questionnaire and its position on the queue
  • 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.
    • 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?
  • 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.
  • Self service tools for scanning by PMCs and PLs (and committers).
  • Foundation-sponsored training for committers around IP responsibilities
  • 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"
  • legal@ should reply to emails in a timely manner
  • It takes too friggin' long.
    • Perhaps we can have quick provisional approvals.

ACTION: [Bjorn FB] pass these along to legal@

Notes taken and posted by Bjorn Freeman-Benson

Back to the top