Mike Milinkovich
Executive Director,
Eclipse Foundation, Inc.
Office: 613-224-9461 x228
Cell: 613-220-3223
mike.milinkovich@xxxxxxxxxxx <mailto:mike.milinkovich@xxxxxxxxxxx>
blog: http://milinkovich.blogspot.com/
------------------------------------------------------------------------
Eclipse Requirements Council Minutes
May 17, 2005, Portland, Oregon
*Present* * * *Regrets*
Paul Clenahan, Actuate
John Kellerman, IBM Corporation
Bjorn Freeman-Benson, Eclipse
Martin Klaus, Wind River
James Saliba, Computer Associates
Melissa Traynor, MontaVista
Georg Lenz, SAP
Mike Milinkovich, Eclipse
Mike Norman, Scapa Technology
Anurag Gupta, Intel
Shane Pearson, BEA
Boris Kapitanski, Serena
Philip Ma, HP
Mike Norman, Scapa
Karl Reti, Sybase
Minutes / Discussion Items
/ (these notes are in chronological order)/
Overiew
Since there were many new members of the Requirements Council, Mike
Milinkovich provided a brief overview of the Roadmap process and how the
Councils had operated in the past. A copy of the presentation materials
can be found here <ReqCouncilOverview.pdf> (.pdf).
Incubation
The Requirements Council had a lengthy discussion on the whether the
Eclipse Development Process needed to implement an incubation stage as
part of the process. The general consensus was that incubation was a
good idea, and that the primary focus for incubation was to focus the
early project start up on community building. Some thoughts on what
incubation does and does not mean include:
* The goal is to have each project foster a demonstrated community
of users.
* Each project must demonstrate that they are operating using an
open and transparent process.
* Incubation is not a statement of quality. In other words, exiting
incubation does not guarantee that the project can or will ship.
* Incubation is a state, not a place. In other words, Eclipse
projects can be incubated within any top-level project. Proposed
projects which have no obvious homes, will be created in the
Technology PMC. A project's decision to be in the Technology PMC
or some other top-level must be PMC open and transparent.
* It is important that the entry and exit criteria be explicitly
defined and that the guidelines be community-based.
* It is recommended that the existing Checkpoint Review in the
Eclipse Development Process be redefined to be the stage at which
projects exit incubation. This will require that the exit criteria
include (amongst others) specific goals for community building.
* Re-organization of existing projects is allowed without
incubation. This is because incubation is really about the skills
of the development team and their experience in community-building.
* It is important that these criteria be enforced, which means that
it is possible that projects can fail incubation.
The Eclipse Foundation needs to define the branding for the state of
"incubation", so that consumers have a clear view of the maturity level
of the project they are using.
For projects which do incubate within the Technology PMC, migrating to
another top-level project would normally be part of exiting incubation.
two axes: incubation X affiliated
cannot be 1.0 in not affiliated and not incubation
Release Numbering and Synchronization
The Requirements Council discussed whether projects need to use a common
version numbering scheme. E.g. if a project is based upon Eclipse 3.1
platform release, then it would use "3.1" as its version number. The
consensus was that project version numbers contain useful information.
For example, they imply a certain level of maturity for the project. As
a result, synchronized numbers are not required (nor even desirable).
That said, there is a strong desire to help users more easily discover
which project releases work together.
There is a strong interest in having the projects synchronize their
releases. The Requirements Council would like to recommend that the
projects define an "opt in" list of projects which ship together. The
current list of such projects includes: Platform, CDT, VE, GEF, EMF,
BIRT, TPTP, WTP. By "synchronized", we literally mean "same day". It is
recognized that for this to happen, some projects (e.g. Platform) may
need to lengthen their end-game in order to get everyone synchronized.
For there to be a realistic attempt at synchronized release dates, three
will need to be a config control committee for the synchronized release
- perhaps this is the Planning Council?
Most projects are expected to ship a major release per year, with patch
releases roughly quarterly. Projects can elect to ship more releases per
year if they so desire. This is typically required for newer projects
which are focused on quickly expanding their functionality. If projects
do make several major release per year, there is a strong desire that
one of those releases sync up with the major synchronized platform release.
Update Manager Sites
There is a requirement that each PMC ensure that there is an update site
for use by the Eclipse update manager.
Requirements Management
There is a need for the Requirements Council to track requirements which
are brought to the RC through to the final deliverables. This is needed
to track the effectiveness of the Requirements Council process.
* Implement a process that tracks the feature requests that the RC
cares about
* Each feature request needs to map to one or more bugs (as tracked
by Bugzilla)
* The status tracking will be based on the Bugzilla status
* Perhaps we need to push for an open source Requirements Management
project at Eclipse?
* Perhaps implement a simple MySQL database that accesses Bugzilla’s
for status reporting? Login credentials for write access would be
given only to RC members.
* Alternative implementation --- perhaps create a product in
Bugzilla for “Requirements Council”?
_*ACTION:*_ Bjorn is to propose a requirements tracking process for
Requirements Council. How will the data be tracked and reported?
Eclipse Quality and Branding
The Requirements Council discussed a number of items related to what it
means for Eclipse projects to ship releases under the Eclipse "brand".
Some of the questions discussed included:
* What should it mean to have the Eclipse brand attached to a project?
* What are the quality requirements?
* How proactive should we be?
* How can we enforce this in an open-source project?
* What role does the RC have in establishing quality objectives for
Eclipse projects?
Below are notes taken during the discussion:
* What role does the Requirements Council have?
o The RC should identity what quality goals the open source
projects should define and implement.
o The RC represent the consumers, so they care deeply about
the quality statements from the projects
o RC would like to see defined policies for:
+ APIs are key --- extensibility for product builders is
key for definition of success
# Maturity states: Low, Medium, High, Platform
# Classification: API (Platform maturity),
provisional (Low, Medium, High maturity), internal
+ Exemplary tools good enough to attract a large number
of adopters is also key
+ Release-to-release migration policies
+ Documentation standards
+ API and backwards compatibility
+ Project maturity model
+ What has the project done to leverage automated test,
community feedback to ensure quality? Each project
should make a statement on what they have done to
ensure quality. There is a clear feeling that having
each project ship an automated test suite is a high
value add for consumers. In fact, the RC would like to
make an automated test suite an exit criteria for
release reviews.
* The RC would like to request that a number of documents which are
Eclipse project only be updated and made applicable to the entire
community (e.g. Eclipse Quality APIs)
* What should it mean to have the Eclipse brand attached to a project?
o This applies to every project shipment of release 1.0 or greater
o Production quality
+ Usability (compelling UI quality). The exemplary tools
really need to be good.
+ Performance and scalability
# Current cross-platform performance and
scalability (e.g. Solaris/Motif, Linux/GTK) need
to improve.
+ Automated tests and/or quality plan
+ Release to release migration, with statements on
source and/or binary compatibility and tools to assist
migration as/where appropriate. This applies not only
to plug-ins, but also the artifacts created by
previous plug-in versions (e.g. models, report
descriptions, etc.)
o API stability (long term!)
o IP due diligence
+ Predictability
o Features, plans and dates were met by the project
+ Demonstrable community involvement and participation
o Open and transparent development processes in place
+ The RC would like explicit coverage of each of these
items in project release review
Requirements for New Projects
The Requirements Council discussed a number of items related to starting
new projects and what set of expectations are appropriate for them. Some
of the questions discussed included:
* Projects should be:
o Easy to propose
o Fairly easy to create
o Kinda hard to validate (e.g. exit incubation)
o Pretty tough to ship
o In other words, the process we have is more-or-less right
* We need to do something with top-level as well. We need PMC
training wheels.
o Top-level projects do need to be in an incubation state for
some period of time
o They exit incubation via a checkpoint review, with the exit
criteria being similar to a sub-project review but with a
few extra ones to check on conformance with the project
charter and governance.
o We need to be a better definition of mentoring PMCs and
documenting what they need to do.
o When doing reviews (creation, checkpoint, release) we need
to explicitly split what is being reviewed that is part of
the top-level project, and what part is made up of the
content of the sub-projects.
_*ACTION:*_ Bjorn and Mike are to define the exit criteria for a
checkpoint review.
/Notes taken and posted by Bjorn Freeman-Benson and Mike Milinkovich/
------------------------------------------------------------------------
_______________________________________________
eclipse.org-requirements-council mailing list
eclipse.org-requirements-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-requirements-council
