Difference between revisions of "Planning Council Agenda"
|(One intermediate revision by the same user not shown)|
|Line 1:||Line 1:|
This page gather for the [http://www.eclipse.org/org/foundation/council.php#planning Eclipse Planning Council] face-to-face .
Latest revision as of 10:12, 5 August 2009
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.
Bjorn will describe the Ganymatic build system and how you will contribute your project.
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.
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  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
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  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.
- Concerns about the Eclipse Top-Level Project splitting streams (3.x vs. 4.0)?
- Performance and scalability. Is there consensus ? Actions to improve ? Measurements ?