‹header›
‹date/time›
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
‹footer›
‹#›
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. Reason: 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 excluded.
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. The project's Architecture Council representative will personally certify that the requirements for quality have been met and/or discuss any deficiences. Reason: Eclipse members build commercial tools on top of the extensible frameworks and thus the quality of the APIs is extremely important.
Summarize the usability of the tools. Usability in this sense is about using the tools to solve development problems, not the more academic sense of UI evaluation/testing. Reason: Without usable tools, the project will not attract the user community necessary to enable the ecosystem.
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 is important.
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 outstanding? 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 issues.
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. Reason: Eclipse is about building frameworks and tools based on standards, so we need to make sure that we are conforming to the appropriate standards.
Summarize the user interface usability of the tools include section 508 compliance, language pack conformance (does the code support multiple languages), etc.. Reason: The user community is larger than just mouse-wielding, English-speaking, computer jockeys. We need to support that larger community.
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. Reason: 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 Process. 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. 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 process of building the community.
Summarize the project's development of its three communities. 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.
As per the Eclipse IP Policy, these steps must be done:
The project leadership verifies that:
... that the about files and use licenses are in place as per the Guidelines to Legal Documentation.
... all contributions (code, documentation, images, etc) has 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. (see below)
... that all significant contributions have been reviewed by the Foundation's legal staff. (see below)
... that all non-committer code contributions, including third-party libraries, have been documented in the release and reviewed by the Foundation's legal staff (see below)
... that all contribution questionnaires have been completed (see below)
... the "provider" field of each plug-in is set to "eclipse.org"
... the "copyright" field of each plug-in is set to the copyright owner.
... that any third-party logos or trademarks included in the distribution (icons, help file logos, etc) have been licensed under the EPL.
... that any fonts or similar third-party images included in the distribution (e.g. in PDF or EPS files) have been licensed under the EPL.
The PMC provides a Project Log that enumerates:
every piece of third party software including information on the license
every major contribution
the name of every contributor including non-committer contributions via bug fixes with bug #'s
the About files which contain any non-standard terms (e.g., a reference to a license other than the EPL, etc)
The EMO will validate for (a) and (b) that contribution questionnaires have been properly submitted and EMO approvals have been completed.
A frozen copy of the reviewed-and-approved-by-Eclipse-legal Project Log is part of the Release Review documentation. It can be included in the slides or as a separate document.
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.
The slides should include reference to the version of this document the Review is based on. Reason: The guidelines are continually evolving and a reader in the future will want to know what version of the guidelines were in place when the Release Review was completed.