Tuesday, August 24, 2005
Here were the main discussion topics, as distributed prior to the meeting:
Quality. Continuing our quality discussion starting with a discussion of the draft Guidelines and the feedback received from the community about these Guidelines. Please note that this documentation also addresses the action item from the last meeting "ACTION: Bjorn and Mike are to define the exit criteria for a checkpoint review."
Roadmap. The days are growing shorter and autumn will be upon us in no time at all, and with autumn comes the Eclipse Roadmap process. Last year's Roadmap is available online.
Mike would like all representatives of Strategic Members to come prepared with their input into the Roadmap process. Last year, each person prepared a brief document and/or presentation on their firm's key requirements and presented them to the RC to help kick-start the process.
Roadmap debrief: What worked last year, what changes would be like to see to the process?
Requirements Tracking. From the minutes of our last meeting: "Bjorn is to propose a requirements tracking process for Requirements Council. How will the data be tracked and reported?"
The Requirements Council approved the draft Guidelines without modification.
The Requirements Council reviewed the themes and priorities approved for 2005 and gave the following assessment of progress.
Design for Extensibility: Be a Better Platform
Rich Client Platform
Simple to Use
Appealing to the Broader Community
No progress made, but high hopes for 2006:
Enable Consistent Multi-language Support
First, there was a general consensus that the themes and priorities established in last year's process are expected to continue “as is”.
In looking ahead to the 2006 Roadmap process, the requirements council observed that the process was low on precision. For example, there was a great deal of effort in creating the themes, but relatively little focus on prioritization. To help address this, this time around:
Each RC member will assign Bugzilla bug #’s to each line item in their RC input.
The RC will attempt to prioritize the input it provides to the AC and PC. (This will be an experiment, success TBD.)
There was a great deal of discussion on how to best track the requirements council inputs in Bugzilla. The alternatives discussed included:
modifying Bugzilla so that we could directly assign themes to bugs;
implementing a separate requirements tracking system and link it to Bugzilla; and
try a simple hack on Bugzilla to track the bugs with a minimal amount of infrastructure support
In the end, the decision was made to pursue the third option. To that end, for each theme, we will create an email list with digest entitled firstname.lastname@example.org. Then each bug will be annotated to put the themes mail id into the cc field for the various bugs that map to the theme. (This would be done by a mix of people, including Council members and project folks.) People interested in the progress on a particular theme can either subscribe to the mail list or read the digest. A similar approach could also be used for bugs which are of particular interest to particular companies
It should be possible to also create BIRT reports which query Bugzilla for particular email addresses in the cc field and report by status
The remainder of the meeting was spent on reviewing the requirement inputs from the council members. A consolidated list of these requirements is below.
Coordinate release of Eclipse projects (IBM)
Roadmap visibility needs to longer than 3 mo timeframes currently in project plans (Borland, HP)
Robust distributed build process
Scalable build processes, robust maintenance, and support for x86, x86_64, and ia64 on Linux and Mac OSX for official Eclipse builds.
Release engineering improvements (Borland)
Certification Program for Plug-ins (HP)
More emphasis on upward
compatibility of public APIs (Actuate)
Issue with GEF was a problem for BIRT 1.0.1 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=103442)
Common project model (Borland, Wind River)
Developers and developer tools think of projects as collections of physical artifacts. Move viewpoint to support methodology and project management.
This requires support for roles linked to capability sets and process definitions. (Roles depend on Process)
Solve the problem of dealing with read-only files and directories by separate project content from project metadata.
Project files (e.g. .project) should be created in the workspace optionally.
Logical Resources (IBM, Borland,
Better support for logical/physical resource separation
Update manager enhancements (IBM, Wind River)
Ability to access resources in other locations than the file system
Better language support (Intel, Wind River)
Support for mixed mode (VM-based + compiled) code development
Develop industrial strength development environments for compiled time languages.
The ability to replace a build system with custom implementations.
Adopt recommendations from the DSDP/DD Project in the Platform Debug model
Shared database engine to store, read, and manipulate data that can be used by multiple plug-ins.
Build Listeners: Listeners that listen to Build Notifications should:
get information about the resources (projects) that are about to be built
be able to hold off the current built until some additional prerequisite is fulfilled
be able to cancel the current build if desired
Accessibility (Section 508)
Support (Actuate, but general agreement)
The belief is that Eclipse has strong support for accessibility, but need guidelines to ensure projects conform in a standard way
Progress on Vista, nee Longhorn (IBM)
Better Linux support (Intel, HP)
Make Eclipse as good on Linux as it is on Windows.
Use LSB packaging by default
GTK Improvements such as performance, accessibility, globalization
Better Unix Support (Wind River)
Better support for Solaris and Motif-based window managers. Quality is a real issue on Solaris
Support for remote X connections. Eclipse is pretty much unusable over a slow network connection:
Include an open source JDK
e.g. SableVM, Harmony JVM
Grow OSGi community at Eclipse.org (IBM)
Support for all commonly used
standard views for RCP applications (Actuate)
Today: Navigator and Problems view both require full IDE framework and are not intended for use with RCP applications
Improve Eclipse configurability to enable more effective control of welcome screen, splash, and perspective (Intel)
Monitoring and systems management solution (Intel)
Support for JMX (HP)