Click to edit Master text styles
Summarize the major features of this
release as well as any other features that have generated significant
discussion amongst the community during the development cycle. Compare the
features against the Roadmap to understand the project's conformance or
divergence (note: compare against the Project Plan section as the forward
looking sections apply to the next release). References to existing New &
Noteworthy documentation is a useful addition to this summary.
The community will use this release and the ecosystem will build products
on top of this release, and both need to know what features were included or
Summarize the state of the non-code
aspects of the release including: user documentation,
localization/externalization, examples, tutorials, articles, and so on. Have
the existing artifacts been updated? Are there new artifacts? Have the
obsolete ones been retired or at least marked as pertaining only to older material?
Reason: The non-code aspects are essential for the
wide-spread adoption of the release.
Certify that the APIs in this release
are Eclipse Quality
. (See the Eclipse Quality APIs
document for more discussion.) The project's Architecture Council
representative will personally certify that the requirements for quality have
Eclipse members build commercial tools on
top of the extensible frameworks and thus the quality of the APIs is extremely
Summarize the architectural quality of
the release. Discuss the intrinsic nature of being extensible
embodied by this project. Discuss issues such as unresolved overlap with other
projects, unpaid "merge debt" from incorporating various components,
and so on.
Reason: Eclipse members build commercial tools
on top of the extensible frameworks and thus the quality of the architecture
Summarize the features (APIs and any
significant user features) from previous releases that are being end-of-life'd
in this release. End of life includes both deprecation and actual removal.
Reason: The community builds products that rely on features
and so they need to know when these features are changing.
Summarize the bugzilla situation. How
many bug records (defects and enhancements) have been
opened/closed/deferred/new, etc? How many P1, P2, ..., bug records are
Reason: Summaries of the bugzilla records
offer a glimpse into the project productivity. They also offer an estimate of
the outstanding risk. And the summary is used to alert the community to known
Summarize the standards compliance of
this release. If the features are based on defined, pending, or ad-hoc
standards, what is the state of those standards and what is the state of the
support for those standards in this release.
is about building frameworks and tools based on standards, so we need to make
sure that we are conforming to the appropriate standards.
Discuss the initial schedule and any
changes to the schedule over the course of the release, i.e., what the project
team achieved. Discuss whether milestones were met or slipped.
The community relies on consistent schedules from Eclipse so that projects and
products can plan for the correct dependencies.
Summarize the project's conformance to
the Eclipse Development
. Has this release been developed using open, transparent, and
inclusive processes? Has this release followed its charter
principles? Consider the use of bugzilla, the mailing lists, the
newsgroups, conference calls, committer elections/removals, etc.
It is important for Eclipse projects to build a community around the project,
not just deliver code for a project. This review item is about the process of
building the community.
Summarize the project's development of
its community. Consider the interactions on bugzilla, the mailing lists, the
newsgroups, public conference calls, blogs, PR activities, code camps,
conference tutorials, coordinating with other Eclipse projects and other open
source projects (Apache, ObjectWeb, etc), ...
Reason: It is
important for Eclipse projects to build a community around the project, not
just deliver code for a project. This review item is about the success of
building a community.
... that the about files and use
licenses are in place
... all contributions (code,
documentation, images, etc) have been committed by individuals who are either
Members of the Foundation, or have signed the appropriate Committer Agreement.
In either case, these are individuals who have signed, and are abiding by, the
Eclipse IP Policy.
... that all significant contributions
have been reviewed by the Foundation's legal staff.
... that all non-committer code
contributions, including third-party libraries, have been documented in the
release and reviewed by the Foundation's legal staff
... that all contribution
questionnaires have been completed
The EMO explicitly asks during the
Release Review if any Member would like to assert that this release infringes
their IP rights. If so, the EMO and the project will follow the Eclipse IP
Policy in discussions with that Member.
One of the
important benefits that the Eclipse Foundation provides for its members is the
consistent application of the Eclipse IP Policy
which helps ensure (but does not guarantee) that the framework and tools are useable
in commercial products.
If there is a Project Plan (full or even
a draft) for the next release, the final issue to cover in the Release Review
is the unveiling of the new plan.