1. 1 Requirements Tracking Alternatives discussed: Modifying Bugzilla Implementing a separate system linked to Bugzilla Simple hack on Bugzilla Alternative selected: simple hack on Bugzilla For each theme, create an email list with digest entitled eclipse.org- theme-theme_name@eclipse.orgeclipse.org- theme-theme_name@eclipse.org Put that 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 theme can either subscribe to the mail list or read the digest It should be possible to also create BIRT reports which query Bugzilla for particular email addresses in the cc field and report by status Similar approach can also be used for bugs which are of particular interest to particular companies

2. 2 Roadmap Process Good news: The themes identified last year are expected to continue as is New focus areas: Last years effort was low on precision Action: Each RC member will assign bug #s to each line item in their RC input To be provided to the PC by end of September for input to 3.2 Last years effort was all about themes. There was little or no prioritization Action: The RC will attempt to prioritize the input it provides to the AC and PC (experiment, success TBD) Community feedback required Action: Prepare a lightweight report card on the completion status of the items identified last year Both at the RC T&P level and the AIP input level To be used at the Member Meeting in September

3. 3 Progress Report Card Preview Progress made: Scaling Up Enterprise Ready 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: Embedded Development Disappointment continues Enable Consistent Multi-language Support

4. 4 Requirements - Process Coordinate release of Eclipse projects (IBM) Patchsets? Roadmap visibility (Borland, HP) Longer than 3 mo timeframes Robust distributed build process (Borland, Intel) 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)https://bugs.eclipse.org/bugs/show_bug.cgi?id=103442

5. 5 Requirements – Extending the Platform 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, Wind River) Better support for logical/physical resource separation Improve Linked Resource Management: Should also work with Import, Add Folder and Add File Update manager enhancements (IBM, Wind River) Extensible Navigator (Actuate) Ability to access resources in other locations than the file system

6. 6 Requirements – Extending the Platform 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. Plug-in profiler 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) Belief is that Eclipse has strong support for accessibility But need guidelines to ensure projects conform in a standard way

7. 7 Requirements - Platforms 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 (HP) 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)

8. 8 Requirements - Lifecycle Monitoring and systems management solution (Intel) Support for JMX (HP)