blob: afa7772c805731288956e46ac65769161a32ba0b [file] [log] [blame]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=windows-1252">
<TITLE></TITLE>
<META NAME="GENERATOR" CONTENT="OpenOffice.org 1.1.3 (Win32)">
<META NAME="AUTHOR" CONTENT="Mike Milinkovich">
<META NAME="CREATED" CONTENT="20051127;15181264">
<META NAME="CHANGEDBY" CONTENT="Mike Milinkovich">
<META NAME="CHANGED" CONTENT="20051202;15314169">
<STYLE>
<!--
@page { size: 21.59cm 27.94cm }
-->
</STYLE>
</HEAD>
<BODY LANG="en-US" DIR="LTR">
<H1>Minutes of Requirements Council Meeting</H1>
<P STYLE="margin-bottom: 0cm">Boston, MA<BR>Tuesday, August 24, 2005</P>
<HR>
<H2>Attendees</H2>
<TABLE WIDTH=457 BORDER=0 CELLPADDING=4 CELLSPACING=0>
<COL WIDTH=135>
<COL WIDTH=157>
<COL WIDTH=2>
<COL WIDTH=131>
<THEAD>
<TR VALIGN=TOP>
<TH COLSPAN=2 WIDTH=300 BGCOLOR="#808080">
<P>Present</P>
</TH>
<TH WIDTH=2>
<P><BR>
</P>
</TH>
<TH WIDTH=131 BGCOLOR="#808080">
<P>Regrets</P>
</TH>
</TR>
</THEAD>
<TBODY>
<TR VALIGN=TOP>
<TD WIDTH=135>
<P>Paul Clenahan
</P>
</TD>
<TD WIDTH=157>
<P>Bjorn Freeman-Benson</P>
</TD>
<TD WIDTH=2>
<P><BR>
</P>
</TD>
<TD WIDTH=131>
<P>Boris Kapitanski</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=135>
<P>Anurag Gupta</P>
</TD>
<TD WIDTH=157>
<P>John Kellerman</P>
</TD>
<TD WIDTH=2>
<P><BR>
</P>
</TD>
<TD WIDTH=131>
<P>Georg Lenz</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=135>
<P>Martin Klaus</P>
</TD>
<TD WIDTH=157>
<P>Philip Ma</P>
</TD>
<TD WIDTH=2>
<P><BR>
</P>
</TD>
<TD WIDTH=131>
<P>Mike Norman</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=135>
<P>Mike Milinkovich</P>
</TD>
<TD WIDTH=157>
<P>Karl Reti</P>
</TD>
<TD WIDTH=2>
<P><BR>
</P>
</TD>
<TD WIDTH=131>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=135>
<P>James Saliba</P>
</TD>
<TD WIDTH=157>
<P>Melissa Traynor</P>
</TD>
<TD WIDTH=2>
<P><BR>
</P>
</TD>
<TD WIDTH=131>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=135>
<P>Karl Frank</P>
</TD>
<TD WIDTH=157>
<P><BR>
</P>
</TD>
<TD WIDTH=2>
<P><BR>
</P>
</TD>
<TD WIDTH=131>
<P><BR>
</P>
</TD>
</TR>
</TBODY>
</TABLE>
<P><BR><BR>
</P>
<H2>Agenda</H2>
<P>Here were the main discussion topics, as distributed prior to the
meeting:</P>
<UL>
<LI><P STYLE="margin-bottom: 0cm"><B>Quality.</B> Continuing our
quality discussion starting with a discussion of <A HREF="http://www.eclipse.org/org/processes/Guidelines_for_Eclipse_Development_Process/">the
draft Guidelines</A> and the feedback received from the community
about these Guidelines. Please note that this documentation also
addresses the action item from the last meeting &quot;ACTION: Bjorn
and Mike are to define the exit criteria for a checkpoint review.&quot;
</P>
<LI><P STYLE="margin-bottom: 0cm"><B>Roadmap. </B>The days are
growing shorter and autumn will be upon us in no time at all, and
with autumn comes the Eclipse Roadmap process. <A HREF="http://www.eclipse.org/org/councils/roadmap.html">Last
year's Roadmap is available online</A>.
</P>
<OL>
<LI><P STYLE="margin-bottom: 0cm">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.
</P>
<LI><P STYLE="margin-bottom: 0cm">Roadmap debrief: What worked last
year, what changes would be like to see to the process?
</P>
</OL>
<LI><P><B>Requirements Tracking.</B> From the minutes of our last
meeting: &quot;Bjorn is to propose a requirements tracking process
for Requirements Council. How will the data be tracked and
reported?&quot;
</P>
</UL>
<H2>Quality</H2>
<P>The Requirements Council approved <A HREF="http://www.eclipse.org/org/processes/Guidelines_for_Eclipse_Development_Process/">the
draft Guidelines</A> without modification.</P>
<H2>Roadmap Process</H2>
<H3>Progress Review from 2005 Roadmap</H3>
<P>The Requirements Council reviewed the themes and priorities
approved for 2005 and gave the following assessment of progress.</P>
<P STYLE="margin-left: 2cm"><B>Progress made:</B></P>
<UL>
<LI><P STYLE="margin-bottom: 0cm">Scaling Up
</P>
<LI><P STYLE="margin-bottom: 0cm">Enterprise Ready
</P>
<LI><P STYLE="margin-bottom: 0cm">Design for Extensibility: Be a
Better Platform
</P>
<LI><P STYLE="margin-bottom: 0cm">Rich Client Platform
</P>
<LI><P STYLE="margin-bottom: 0cm">Simple to Use
</P>
<LI><P>Appealing to the Broader Community
</P>
</UL>
<P STYLE="margin-left: 2cm"><B>No progress made, but high hopes for
2006:</B></P>
<UL>
<LI><P>Embedded Development
</P>
</UL>
<P STYLE="margin-left: 2cm"><B>Disappointment continues:</B></P>
<UL>
<LI><P>Enable Consistent Multi-language Support
</P>
</UL>
<H3>2006 Roadmap Process</H3>
<P>First, there was a general consensus that the themes and
priorities established in last year's process are expected to
continue &ldquo;as is&rdquo;.</P>
<P>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:</P>
<OL>
<LI><P STYLE="margin-bottom: 0cm">Each RC member will assign
Bugzilla bug #&rsquo;s to each line item in their RC input.</P>
<LI><P>The RC will attempt to prioritize the input it provides to
the AC and PC. (This will be an experiment, success TBD.)</P>
</OL>
<P>There was a great deal of discussion on how to best track the
requirements council inputs in Bugzilla. The alternatives discussed
included:</P>
<OL>
<LI><P STYLE="margin-bottom: 0cm">modifying Bugzilla so that we
could directly assign themes to bugs;
</P>
<LI><P STYLE="margin-bottom: 0cm">implementing a separate
requirements tracking system and link it to Bugzilla; and</P>
<LI><P>try a simple hack on Bugzilla to track the bugs with a
minimal amount of infrastructure support</P>
</OL>
<P>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 <A HREF="mailto:eclipse.org-theme-theme_name@eclipse.org">eclipse.org-theme-theme_name@eclipse.org</A>.
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</P>
<P>It should be possible to also create BIRT reports which query
Bugzilla for particular email addresses in the cc field and report by
status</P>
<P>The remainder of the meeting was spent on reviewing the
requirement inputs from the council members. A consolidated list of
these requirements is below.</P>
<UL>
<LI><P STYLE="margin-bottom: 0cm">Coordinate release of Eclipse
projects (IBM)</P>
<LI><P STYLE="margin-bottom: 0cm">Roadmap visibility needs to longer
than 3 mo timeframes currently in project plans (Borland, HP)</P>
<LI><P STYLE="margin-bottom: 0cm">Robust distributed build process
(Borland, Intel)<BR>Scalable build processes, robust maintenance,
and support for x86, x86_64, and ia64 on Linux and Mac OSX for
official Eclipse builds.
</P>
<LI><P STYLE="margin-bottom: 0cm">Release engineering improvements
(Borland)</P>
<LI><P STYLE="margin-bottom: 0cm">Certification Program for Plug-ins
(HP)</P>
<LI><P STYLE="margin-bottom: 0cm">More emphasis on upward
compatibility of public APIs (Actuate)<BR>Issue with GEF was a
problem for BIRT 1.0.1
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=103442)</P>
<LI><P STYLE="margin-bottom: 0cm">Common project model (Borland,
Wind River)</P>
<UL>
<LI><P STYLE="margin-bottom: 0cm">Developers and developer tools
think of projects as collections of physical artifacts. Move
viewpoint to support methodology and project management.</P>
<LI><P STYLE="margin-bottom: 0cm">This requires support for roles
linked to capability sets and process definitions. (Roles depend on
Process)</P>
<LI><P STYLE="margin-bottom: 0cm">Solve the problem of dealing with
read-only files and directories by separate project content from
project metadata.
</P>
<LI><P STYLE="margin-bottom: 0cm">Project files (e.g. .project)
should be created in the workspace optionally.
</P>
</UL>
<LI><P STYLE="margin-bottom: 0cm">Logical Resources (IBM, Borland,
Wind River)<BR>Better support for logical/physical resource
separation</P>
<LI><P STYLE="margin-bottom: 0cm">Update manager enhancements (IBM,
Wind River)</P>
<LI><P STYLE="margin-bottom: 0cm">Extensible Navigator
(Actuate)<BR>Ability to access resources in other locations than the
file system</P>
<LI><P STYLE="margin-bottom: 0cm">Better language support (Intel,
Wind River)</P>
<UL>
<LI><P STYLE="margin-bottom: 0cm">Support for mixed mode (VM-based
+ compiled) code development</P>
<LI><P STYLE="margin-bottom: 0cm">Develop industrial strength
development environments for compiled time languages.
</P>
<LI><P STYLE="margin-bottom: 0cm">The ability to replace a build
system with custom implementations.</P>
<LI><P STYLE="margin-bottom: 0cm">Adopt recommendations from the
DSDP/DD Project in the Platform Debug model</P>
</UL>
<LI><P STYLE="margin-bottom: 0cm">Shared database engine to store,
read, and manipulate data that can be used by multiple plug-ins.
</P>
<LI><P STYLE="margin-bottom: 0cm">Plug-in profiler</P>
<LI><P STYLE="margin-bottom: 0cm">Build Listeners: Listeners that
listen to Build Notifications should:
</P>
<UL>
<LI><P STYLE="margin-bottom: 0cm">get information about the
resources (projects) that are about to be built</P>
<LI><P STYLE="margin-bottom: 0cm">be able to hold off the current
built until some additional prerequisite is fulfilled</P>
<LI><P STYLE="margin-bottom: 0cm">be able to cancel the current
build if desired</P>
</UL>
<LI><P STYLE="margin-bottom: 0cm">Accessibility (Section 508)
Support (Actuate, but general agreement)<BR>The belief is that
Eclipse has strong support for accessibility, but need guidelines to
ensure projects conform in a standard way</P>
<LI><P STYLE="margin-bottom: 0cm">Progress on Vista, nee Longhorn
(IBM)</P>
<LI><P STYLE="margin-bottom: 0cm">Better Linux support (Intel, HP)</P>
<UL>
<LI><P STYLE="margin-bottom: 0cm">Make Eclipse as good on Linux as
it is on Windows.</P>
<LI><P STYLE="margin-bottom: 0cm">Use LSB packaging by default</P>
<LI><P STYLE="margin-bottom: 0cm">GTK Improvements such as
performance, accessibility, globalization</P>
</UL>
<LI><P STYLE="margin-bottom: 0cm">Better Unix Support (Wind River)</P>
<UL>
<LI><P STYLE="margin-bottom: 0cm">Better support for Solaris and
Motif-based window managers. Quality is a real issue on Solaris</P>
<LI><P STYLE="margin-bottom: 0cm">Support for remote X connections.
Eclipse is pretty much unusable over a slow network connection:
</P>
</UL>
<LI><P STYLE="margin-bottom: 0cm">Include an open source JDK
(HP)<BR>e.g. SableVM, Harmony JVM</P>
<LI><P STYLE="margin-bottom: 0cm">Grow OSGi community at Eclipse.org
(IBM)</P>
<LI><P STYLE="margin-bottom: 0cm">Support for all commonly used
standard views for RCP applications (Actuate)<BR>Today: Navigator
and Problems view both require full IDE framework and are not
intended for use with RCP applications</P>
<LI><P STYLE="margin-bottom: 0cm">Improve Eclipse configurability to
enable more effective control of welcome screen, splash, and
perspective (Intel)</P>
<LI><P STYLE="margin-bottom: 0cm">Monitoring and systems management
solution (Intel)</P>
<LI><P STYLE="margin-bottom: 0cm">Support for JMX (HP)</P>
</UL>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
</BODY>
</HTML>