Requirements Tracking Alternatives discussed Modifying Bugzilla Implementing a

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. orgtheme-theme_name@eclipse. org § Put that mail id into the cc field for the various bugs that map to 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 1

Roadmap Process § Good news: § The themes identified last year are expected to continue “as is” § New focus areas: § Last year’s 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 year’s 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 2

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 3

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 x 86, x 86_64, and ia 64 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) 4

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 5

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 fulfilled prerequisite is § 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 6

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. Sable. VM, 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) 7

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