Planning Council Agenda

This page is where we can gather the agenda for the next Eclipse Planning Council face-to-face.

Location

The next face-to-face will be at EclipseCon in Santa Clara, CA on Sunday, March 16th. We will have coordination phone calls before then.

Agenda

MOREMORE

Ganymatic

Bjorn will describe the Ganymatic build system and how you will contribute your project.

Brand/Trademark

Just a note that the Eclipse project name policy defines "Eclipse Ganymede" as an Eclipse Foundation brand/trademark for the benefit of the Eclipse community. This means that the Eclipse Foundation (a.k.a. the EMO) controls where the trademark is used, how it can be incorporated in corporate advertising, etc.

Supported Platforms

The BIRT team suggests: There should be a set of supported platforms that all participating Eclipse projects agree to support. With the amount of inter-dependence between Eclipse projects, letting each project decide on its own will cause more confusion in the community. An example would be java 5 support in Europa. BIRT wasn't planning on requiring it, until we were surprised and forced to by WTP and EMF deciding without consulting us.

At the very least, let's avoid surprises. Better yet, let's work on a process by which we can collectively decide to add or remove supported platforms.

I agree, it's important to let people know about changes like these, and IMHO, we did. See EMF 2.3 Plan History for details. We gave people ample time between posting the plan and committing the changes (over 4 months), so that objections could be raised -- and none were. If we could have done better, please let us know how. --nickb 11:33, 5 October 2007 (EDT)

I want to add that BIRT project is aware of the change of requiring Java 5 support in Europa. The BIRT PMC has discussed this topic, see this meeting minute [1] and agreed to supporting Java 5. Some project members might have expressed strong opinion about this requirement, but the project as a whole did reach an agreement. --wli

Packages

The Europa releases included four packages on the download page. This proved to be quite successful and we're planning to do at least the same thing for Ganymede. However one critique of the packages last year was that there was inadequate cross-project testing within the packages. So this year the projects that are incorporated into the packages need to agree to do some cross-project testing. Specifically, they need to agree to do their usual testing with the package rather than just with their own project image.

Internationalization

Perhaps a Babel project update. At least a discussion of how projects would like to (scripts?) contribute to, and consume, the Babel translations.

Community-Based Testing

What can we, as leaders of Eclipse projects, do to encourage more community-based testing? I've been bringing up the idea of a CPAN-like testing system [2] for Eclipse for a number of meetings, but I'd like to do more than talk. Let's discuss options that do not involve big new mandates on the projects and yet get our community more involved in testing the Eclipse packages and distros.

Discussion

• How can we make Ganymede better than Europa?
• Should we agree to rules about conformance UI guidelines? About framework integration at the UI or API levels?
• How do we guarantee early adoption of intermediate milestones of between projects rather than waiting for last minute integration testing?
• How do we ensure API cleanliness (i.e. not relying on other project's internals)?
• Concerns about the Eclipse Top-Level Project splitting streams (3.x vs. 4.0)?
• Performance and scalability. Is there consensus ? Actions to improve ? Measurements ?
• Enforcement:

A line in Ganymede plan says "Unlike the somewhat lax enforcement of previous years, the EMO will remove projects that do not meet the required constraints."

Since such issues often involve a cost-benefit analysis or trade off, I suggest we build-in a Planning Council mechanism that allows for reasonable exceptions. Besides allowing for exceptions, this might help avoid being too cautious on saying what is "required". For example, my suggested wording would be, "If projects do not meet the required constraints, they will be removed from the Ganymede release unless

1. The project applies for an exception that is reviewed and approved by majority vote of the Planning Council (that is, majority vote with no substantial objections).
2. The project has a plan for rectifying the non-compliant item by the next coordinated yearly release. Exceptions can not be granted two years in a row -- either compliance will be achieved, or the rule changed.

(added by David Williams 10/30).