Minutes of Requirements Council Meeting

["Mike Milinkovich" <mike.milinkovich@xxxxxxxxxxx>]

I realized over the weekend that I never distributed the minutes of our last meeting. Please see attached. I would appreciate any comments you may have.

 

These were based off of the presentation we created for the plenary session. (Also attached)

 

Comments welcomed. I think I missed one or two attendees, so please let me know if I missed you.

 

Mike Milinkovich
Executive Director,
Eclipse Foundation, Inc.
Office: 613-224-9461 x228
Cell: 613-220-3223
mike.milinkovich@xxxxxxxxxxx

 

blog: http://milinkovich.blogspot.com/

 

Attachment: RC Summary for Plenary.ppt
Description: MS-Powerpoint presentation

Minutes of Requirements Council Meeting

Boston, MA
Tuesday, August 24, 2005

---

Attendees

Present			Regrets
Paul Clenahan	Bjorn Freeman-Benson		Boris Kapitanski
Anurag Gupta	John Kellerman		Georg Lenz
Martin Klaus	Philip Ma		Mike Norman
Mike Milinkovich	Karl Reti
James Saliba	Melissa Traynor

Agenda

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.

  1. 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.

  2. 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?"

Quality

The Requirements Council approved the draft Guidelines without modification.

Roadmap Process

Progress Review from 2005 Roadmap

The Requirements Council reviewed the themes and priorities approved for 2005 and gave the following assessment of progress.

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

2006 Roadmap Process

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:

1. Each RC member will assign Bugzilla bug #’s to each line item in their RC input.

2. 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:

1. modifying Bugzilla so that we could directly assign themes to bugs;

2. implementing a separate requirements tracking system and link it to Bugzilla; and

3. 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 eclipse.org-theme-theme_name@xxxxxxxxxxx. 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 (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)

• 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

• Update manager enhancements (IBM, Wind River)

• Extensible Navigator (Actuate)
  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.

• 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)
  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 (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)

• Monitoring and systems management solution (Intel)

• Support for JMX (HP)