doc/releaseReview.1.1.0/epp_1.1.0_ReleaseReview.tex - epp/org.eclipse.epp.doc.release - Git at Google

 \documentclass{report}
 \input{./common/setup.tex}
 %\usepackage{picins}
 \usepackage{longtable}


 \renewcommand{\textfraction}{0.01}
 \renewcommand{\topfraction}{1,}
 \renewcommand{\bottomfraction}{1.}
 %%%%%%%%%%%%%%%%%%%%%%%%    DEFINITIONS    %%%%%%%%%%%%%%%%%%%%%%%%
 \def\docfilename{}
 \def\title{Eclipse Packaging Project}
 \def\subtitle{Release Review Version 1.1.0}
 \def\everypagetitle{\textbf{Eclipse Technology Project: EPP\\Release Review
 Version 1.1.0}} \def\pubdate{\today}
 \def\workpackage{}
 \def\partners{}
 \def\leadpartner{}
 \def\configid{}
 \def\docclassification{\copyright 2009 by Markus Knauer.\newline
 Made available under the Eclipse Public License v1.0.}
 \def\istnumber{}
 \def\abstract{This document contains the Release Review Documentation for the
 Eclipse Packaging Project (EPP). The 1.1.0 EPP release is scheduled for
 2009-06-24 together with the release of Galileo.}

 \makeindex

 \begin{document}

 \input{./common/cover}

 %\vspace*{8cm}
 %\begin{center}
 %This document is intended to be gender-neutral. Nevertheless, we use gender-specific language where expedient to ensure simplicity.
 %\end{center}

 %\clearpage

 %\section*{Delivery Slip}
 %\begin{tabular}{|p{2.1cm}|p{4.1cm}|p{2.0cm}|p{2.0cm}|p{3.7cm}|}
 %\hline
 %                        & Name  & Partner & Date    &  Signature \\ \hline
 %\hline
 %\raggedleft From        & Markus Knauer & INO &     &            \\ \hline
 %\raggedleft Verified By &       &         &         &            \\ \hline
 %\raggedleft Approved By &       &         &         &            \\ \hline
 %\end{tabular}

 %\section*{Document Log}
 %\begin{tabular}{|p{1.0cm}|p{1.9cm}|p{6cm}|p{5.4cm}|}
 %\hline
 %Version & Date       & Summary of changes & Author  \\ \hline \hline
 % 0.1    & 2007-07-05 & First Draft        & Markus Knauer \\  \hline
 %\end{tabular}

 \tableofcontents
 \newpage

 \chapter{Overview}

 \section{Scope and goals of the project}

 \begin{itemize}
  \item {\bfseries Create entry level downloads based on defined user profiles.} The project defined and created the EPP downloads of Eclipse IDE for Java Developers, Eclipse IDE for Java EE Developers, Eclipse IDE for C/C++ Developers, and Eclipse for RCP/Plug-in Developers. These downloads are available from the main Eclipse download page. In addition to that, other packages maintained by the community and coordinated by EPP are being made available, such as Eclipse IDE for PHP Developers, Eclipse Modeling Tools, Eclipse IDE for Java and Report Developers, and Pulsar for Mobile Java Developers.
  \item {\bfseries Provide and integrate the EPP Usage Data Collector.} The Usage Data Collector collects information about how individuals are using the Eclipse platform. The intent is to use this data to help committers and organizations better understand how developers are using Eclipse.
  \item {\bfseries Provide a dynamic installer that improves the install experience of new users of Eclipse.}
  \item {\bfseries Help projects to integrate with each other.} With the package centric approach it is possible to build products which contain features of many different Eclipse projects. This leads to an early detection of dependency problems, better integration testing, and a project sturcture that is easier to consume.
  \item {\bfseries Provide a central build infrastructure for the eclipse.org package builds.} The EPP package builds are running on Hudson and allow early feedback on the content of the release streams (Europa, Ganymede, Galileo).
 \end{itemize}

 Since June 2007, the project delivered packages for all release trains, including Europa, Ganymede and all of their service releases and had millions of downloads.

 \chapter{Features}

 EPP for Galileo in version 1.1.0 includes

 \begin{itemize}
   \item Buckminster scripts that generate the p2 repository with the package definitions
   \item build scripts that are used in the nightly package builds
   \item the UDC (Usage Data Collector) that collects data on an Eclipse client, e.g. an EPP package and sends the data back to the Eclipse Foundation servers.
 \end{itemize}

 Note that the version number of the packages (currently 1.2.0 for Galileo) is independent from the version number of the software that is used by and delivered by the EPP project.

 \begin{description}
 \item[\texttt{org.eclipse.usagedata.*}] client components of the Eclipse Usage Data Collector. The usage data monitors what is being used and when (timestamp), including
 	\begin{itemize}
     \item Loaded bundles
     \item Commands accessed via keyboard shortcuts
     \item Actions invoked via menus or toolbars
     \item Perspective changes
     \item View usage
     \item Editor usage
     \item Environment, JVM, platform (new)
     \end{itemize}
 Captured data is associated with a user through a combination of workstation and workspace ids that are automatically generated by the collector.  This identification is not tied to any personal information about the user. Where possible, the usage data collector also capture the symbolic name and version of the bundle contributing the command/action/perspective/view/editor.
 \end{description}

 \begin{figure}[!h]
 \begin{center}
 \includegraphics[width=0.80\textwidth]{img/epp.udc.uploading.eps}
 \caption{EPP Usage Data Collector Upload}
 \label{fig:epp.udc.preferences}
 \end{center}
 \end{figure}

 \begin{figure}[!h]
 \begin{center}
 \includegraphics[width=0.80\textwidth]{img/epp.udc.preview.eps}
 \caption{EPP Usage Data Collector Preview}
 \label{fig:epp.udc.preferences}
 \end{center}
 \end{figure}

 % 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.
 % 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.
 % References to existing New and Noteworthy documentation is a useful addition to this summary.

 \chapter{Non-Code Aspects}
 \section{User Documentation}
 User documentation has been created and updated for this release in the form of web pages or wiki pages (http://wiki.eclipse.org/index.php/Category:EPP):
 \begin{itemize}
   \item How-to specify an EPP configuration file
   \item How-to create the package definition files, package defining feature, branding plug-in
   \item How-to build your own package
   \item Package Testing
   \item Build Infrastructure
 \end{itemize}

 \section{Localization or Externalization}
 EPP is available for the English language; strings are externalized.

 Components in Babel are provided but the team does not translate the strings.

 \chapter{APIs}

 \section{EPP Packaging}
 The mechanism how the packages are generated has been changed since the last release. The former technology was build on top of the Eclipse update manager technology. Since this technology is now deprecated and Galileo relies on the usage of the new p2 technology, EPP had to change its own underlying technology.

 EPP packages are now build in two steps and allow every modification that is possible with the standard Eclipse branding.

 \begin{enumerate}
   \item Create a p2 repository with the package metadata; automated with technology from the Buckminster project.
   \item Use the p2 metadata from step 1 in order to create the packages with the p2 director application.
 \end{enumerate}

 The old XML configuration file with a format specified by EPP\footnote{http://wiki.eclipse.org/EPP/Configuration\_File\_Format} is used to generate the web pages only. The package definition is using standard Eclipse technology, such as features and plugins for branding.

 \section{EPP UDC}
 The EPP UDC functionality is split into

 \begin{description}
 \item[\texttt{org.eclipse.epp.usagedata.gathering}] which defines the \\ \texttt{org.eclipse.epp.usagedata.gathering.monitors} extension point; this extension point is used to plug new monitors to Eclipse. Three monitor implementations are included: PartUsageMonitor, BundleUsageMonitor, CommandUsageMonitor. And it defines the \\ \texttt{org.eclipse.epp.usagedata.listeners.event} extension point; implementators act as receiver of the events generated by the monitors.
 \item[\texttt{org.eclipse.epp.usagedata.recording}] which defines the \\ \texttt{org.eclipse.epp.usagedata.recording.uploader} extension point; this extension point allows the creation of different systems to process the data collection.
 \item[\texttt{org.eclipse.epp.usagedata.ui}] defines the UI elements (i.e. preferences pages) and provides an implementation of the uploader extension point that uploads the UDC data to an Eclipse Foundation server.
 \end{description}

 %Certify that the APIs in this release are Eclipse Quality. The project lead 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.


 \chapter{Architectural Issues}

 \section{EPP Packaging}

 The EPP configuration file is not used any more for the package build. Using Eclipse standards, such as feature.xml, etc.

 \section{EPP Usage Data Collector}

 The current implementation of the UDC works in an RCP environment. Future planned enhancements include a UDC that will run unmodified in a RAP environment.

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

 \chapter{Tool Usability}

 \section{EPP Packaging}

 With millions of downloads in the last 2 years, packages generated by EPP have been proven stable.

 The EPP packages are available from the main eclipse.org download page and all community packages from a Drupal driven site.

 \section{EPP Usage Data Collector}

 More than 120.000 users of the Ganymede Packages already send their UDC data to the Eclipse Foundation every month. The results are available from the Eclipse Foundation web pages \\ (http://www.eclipse.org/org/usagedata/).


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

 \chapter{End-of-Life}

 The EPP packaging application cannot be supported any more. The project uses now existing technology from Equinox p2.

 \chapter{Bugzilla}

 As of 2009-06-01 there are $347$ bugs in technology/epp, $126$ listed with status new, assigned, open. There are no blockers, 5 critical bugs. In the end, there will be no blockers left and all critical bugs for 1.1.0 will be fixed until the release.

 \chapter{Standards}

 \begin{itemize}
   \item EPP uses Java 1.5, compatible with Eclipse 3.4 and 3.5.
  \end{itemize}

 \chapter{UI Usability}

 Only the EPP UDC contains UI elements in form of preferences pages.

 \begin{itemize}
   \item Following Eclipse UI usability guidelines
   \item Usability changes based on users' feedback
 \end{itemize}

 %Summarize the user interface usability and the conformance to the Eclipse User Interface Guidelines. Include section 508 compliance, language pack conformance (does the code support multiple languages), etc. Explain any deviations from the user interface guidelines and standards.
 %Reason: The user community is larger than just mouse-wielding, English-speaking, computer jockeys. We need to support that larger community.

 \chapter{Schedule}

 The plan of the Eclipse Packaging Project is always in parallel with the release train plans, i.e. the Galileo release train (http://www.eclipse.org/projects/project-plan.php?projectid=technology.packaging).

 The scheduled dates for the Ganymede release have been met and the packages were released together with the Ganymede Release in June 2008. Updates have been created and made available for all Ganymede Service Releases.

 For the Galileo release, EPP started to deliver initial packages for Galileo M6, and provided regular package builds based on the new build system with Galileo M7. Since then, EPP delivers all packages for each of the Galileo milestones and release candidates.

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

 \chapter{Communities}

 \begin{itemize}
   \item Active committers (6) and contributors from 4 partners (EclipseSource Inc., Eclipse Foundation, Cloudsmith Inc., Instantiations, Xored)
   \item Participation (Talks) at Eclipse events (EclipseSummit 2008, Eclipse\-Con 2009)
   \item Public conference calls
   \item Developer mailing list with about 630 e-mails, newsgroup with more than 200 messages
   \item The Eclipse Packaging Project has been mentioned in many blog postings, other mailing lists (e.g. cross-project-issues-dev)
   \item Participation in the Eclipse Planning Council and in the Eclipse Architecture Council
 \end{itemize}


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

 \chapter{IP Issues}

 See IP Log at http://www.eclipse.org/projects/ip\_log.php?projectid=technology.packaging

 \begin{itemize}
   \item Initial code contribution got IP clearance from Eclipse Legal (bug 244666)
   \item External contributions are listed in the IP Log and were submitted via Bugzilla
 \end{itemize}

 List of committers:

 \begin{itemize}
   \item Wayne Beaton - committer since 12/2007
   \item Henrik Lindberg - committer since 06/2008
   \item Jordi Böhme López - committer since 06/2008
   \item Alexander Kazantsev, initial committer
   \item Markus Knauer, initial committer
   \item Jeff McAffer - committer since 06/2008
   \item Dan Rubel, initial committer
   \item Mark Russell, initial committer
 \end{itemize}

 Committer emeritus (committers who have been removed from the list of EPP committers during the last 12 months):

 \begin{itemize}
   \item Elias Volanakis, initial committer
   \item Leif Frenzel, initial committer
 \end{itemize}

 %As per the Eclipse IP Policy, these steps must be done:
 %   1. 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.
 %          * ... that all significant contributions have been reviewed by the Foundation's legal staff. Include references to the IPZilla numbers of all clearances.
 %          * ... that all non-Committer code contributions, including third-party libraries, have been documented in the release and reviewed by the Foundation's legal staff. Include references to the IPZilla numbers of all clearances.
 %          * ... that all Contribution Questionnaires have been completed
 %          * ... the "provider" field of each feature is set to "Eclipse.org"
 %          * ... the "copyright" field of each feature is set to the copyright owner (the Eclipse Foundation is rarely 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.
 %   2. The PMC provides a Project Log that enumerates:
 %         1. every piece of third party software including information on the license
 %         2. every major contribution
 %         3. the name of every contributor including non-committer contributions via bug fixes with bug number's
 %         4. the About files which contain any non-standard terms (e.g., a reference to a license other than the EPL, etc)
 %   3. The EMO will validate for (a) and (b) that Contribution Questionnaires have been properly submitted and EMO approvals have been completed.
 %   4. 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 docuware or as a separate document.

 \chapter{Project Plan}

 Version 1.1.1 is scheduled for October 2009 (Galileo SR1) and will contain mainly bugfixes.

 A detailed plan is not yet available.

 \end{document}
	\documentclass{report}
	\input{./common/setup.tex}
	%\usepackage{picins}
	\usepackage{longtable}


	\renewcommand{\textfraction}{0.01}
	\renewcommand{\topfraction}{1,}
	\renewcommand{\bottomfraction}{1.}
	%%%%%%%%%%%%%%%%%%%%%%%% DEFINITIONS %%%%%%%%%%%%%%%%%%%%%%%%
	\def\docfilename{}
	\def\title{Eclipse Packaging Project}
	\def\subtitle{Release Review Version 1.1.0}
	\def\everypagetitle{\textbf{Eclipse Technology Project: EPP\\Release Review
	Version 1.1.0}} \def\pubdate{\today}
	\def\workpackage{}
	\def\partners{}
	\def\leadpartner{}
	\def\configid{}
	\def\docclassification{\copyright 2009 by Markus Knauer.\newline
	Made available under the Eclipse Public License v1.0.}
	\def\istnumber{}
	\def\abstract{This document contains the Release Review Documentation for the
	Eclipse Packaging Project (EPP). The 1.1.0 EPP release is scheduled for
	2009-06-24 together with the release of Galileo.}

	\makeindex

	\begin{document}

	\input{./common/cover}

	%\vspace*{8cm}
	%\begin{center}
	%This document is intended to be gender-neutral. Nevertheless, we use gender-specific language where expedient to ensure simplicity.
	%\end{center}

	%\clearpage

	%\section*{Delivery Slip}
	%\begin{tabular}{\|p{2.1cm}\|p{4.1cm}\|p{2.0cm}\|p{2.0cm}\|p{3.7cm}\|}
	%\hline
	% & Name & Partner & Date & Signature \\ \hline
	%\hline
	%\raggedleft From & Markus Knauer & INO & & \\ \hline
	%\raggedleft Verified By & & & & \\ \hline
	%\raggedleft Approved By & & & & \\ \hline
	%\end{tabular}

	%\section*{Document Log}
	%\begin{tabular}{\|p{1.0cm}\|p{1.9cm}\|p{6cm}\|p{5.4cm}\|}
	%\hline
	%Version & Date & Summary of changes & Author \\ \hline \hline
	% 0.1 & 2007-07-05 & First Draft & Markus Knauer \\ \hline
	%\end{tabular}

	\tableofcontents
	\newpage

	\chapter{Overview}

	\section{Scope and goals of the project}

	\begin{itemize}
	\item {\bfseries Create entry level downloads based on defined user profiles.} The project defined and created the EPP downloads of Eclipse IDE for Java Developers, Eclipse IDE for Java EE Developers, Eclipse IDE for C/C++ Developers, and Eclipse for RCP/Plug-in Developers. These downloads are available from the main Eclipse download page. In addition to that, other packages maintained by the community and coordinated by EPP are being made available, such as Eclipse IDE for PHP Developers, Eclipse Modeling Tools, Eclipse IDE for Java and Report Developers, and Pulsar for Mobile Java Developers.
	\item {\bfseries Provide and integrate the EPP Usage Data Collector.} The Usage Data Collector collects information about how individuals are using the Eclipse platform. The intent is to use this data to help committers and organizations better understand how developers are using Eclipse.
	\item {\bfseries Provide a dynamic installer that improves the install experience of new users of Eclipse.}
	\item {\bfseries Help projects to integrate with each other.} With the package centric approach it is possible to build products which contain features of many different Eclipse projects. This leads to an early detection of dependency problems, better integration testing, and a project sturcture that is easier to consume.
	\item {\bfseries Provide a central build infrastructure for the eclipse.org package builds.} The EPP package builds are running on Hudson and allow early feedback on the content of the release streams (Europa, Ganymede, Galileo).
	\end{itemize}

	Since June 2007, the project delivered packages for all release trains, including Europa, Ganymede and all of their service releases and had millions of downloads.

	\chapter{Features}

	EPP for Galileo in version 1.1.0 includes

	\begin{itemize}
	\item Buckminster scripts that generate the p2 repository with the package definitions
	\item build scripts that are used in the nightly package builds
	\item the UDC (Usage Data Collector) that collects data on an Eclipse client, e.g. an EPP package and sends the data back to the Eclipse Foundation servers.
	\end{itemize}

	Note that the version number of the packages (currently 1.2.0 for Galileo) is independent from the version number of the software that is used by and delivered by the EPP project.

	\begin{description}
	\item[\texttt{org.eclipse.usagedata.*}] client components of the Eclipse Usage Data Collector. The usage data monitors what is being used and when (timestamp), including
	\begin{itemize}
	\item Loaded bundles
	\item Commands accessed via keyboard shortcuts
	\item Actions invoked via menus or toolbars
	\item Perspective changes
	\item View usage
	\item Editor usage
	\item Environment, JVM, platform (new)
	\end{itemize}
	Captured data is associated with a user through a combination of workstation and workspace ids that are automatically generated by the collector. This identification is not tied to any personal information about the user. Where possible, the usage data collector also capture the symbolic name and version of the bundle contributing the command/action/perspective/view/editor.
	\end{description}

	\begin{figure}[!h]
	\begin{center}
	\includegraphics[width=0.80\textwidth]{img/epp.udc.uploading.eps}
	\caption{EPP Usage Data Collector Upload}
	\label{fig:epp.udc.preferences}
	\end{center}
	\end{figure}

	\begin{figure}[!h]
	\begin{center}
	\includegraphics[width=0.80\textwidth]{img/epp.udc.preview.eps}
	\caption{EPP Usage Data Collector Preview}
	\label{fig:epp.udc.preferences}
	\end{center}
	\end{figure}

	% 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.
	% 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.
	% References to existing New and Noteworthy documentation is a useful addition to this summary.

	\chapter{Non-Code Aspects}
	\section{User Documentation}
	User documentation has been created and updated for this release in the form of web pages or wiki pages (http://wiki.eclipse.org/index.php/Category:EPP):
	\begin{itemize}
	\item How-to specify an EPP configuration file
	\item How-to create the package definition files, package defining feature, branding plug-in
	\item How-to build your own package
	\item Package Testing
	\item Build Infrastructure
	\end{itemize}

	\section{Localization or Externalization}
	EPP is available for the English language; strings are externalized.

	Components in Babel are provided but the team does not translate the strings.

	\chapter{APIs}

	\section{EPP Packaging}
	The mechanism how the packages are generated has been changed since the last release. The former technology was build on top of the Eclipse update manager technology. Since this technology is now deprecated and Galileo relies on the usage of the new p2 technology, EPP had to change its own underlying technology.

	EPP packages are now build in two steps and allow every modification that is possible with the standard Eclipse branding.

	\begin{enumerate}
	\item Create a p2 repository with the package metadata; automated with technology from the Buckminster project.
	\item Use the p2 metadata from step 1 in order to create the packages with the p2 director application.
	\end{enumerate}

	The old XML configuration file with a format specified by EPP\footnote{http://wiki.eclipse.org/EPP/Configuration\_File\_Format} is used to generate the web pages only. The package definition is using standard Eclipse technology, such as features and plugins for branding.

	\section{EPP UDC}
	The EPP UDC functionality is split into

	\begin{description}
	\item[\texttt{org.eclipse.epp.usagedata.gathering}] which defines the \\ \texttt{org.eclipse.epp.usagedata.gathering.monitors} extension point; this extension point is used to plug new monitors to Eclipse. Three monitor implementations are included: PartUsageMonitor, BundleUsageMonitor, CommandUsageMonitor. And it defines the \\ \texttt{org.eclipse.epp.usagedata.listeners.event} extension point; implementators act as receiver of the events generated by the monitors.
	\item[\texttt{org.eclipse.epp.usagedata.recording}] which defines the \\ \texttt{org.eclipse.epp.usagedata.recording.uploader} extension point; this extension point allows the creation of different systems to process the data collection.
	\item[\texttt{org.eclipse.epp.usagedata.ui}] defines the UI elements (i.e. preferences pages) and provides an implementation of the uploader extension point that uploads the UDC data to an Eclipse Foundation server.
	\end{description}

	%Certify that the APIs in this release are Eclipse Quality. The project lead 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.


	\chapter{Architectural Issues}

	\section{EPP Packaging}

	The EPP configuration file is not used any more for the package build. Using Eclipse standards, such as feature.xml, etc.

	\section{EPP Usage Data Collector}

	The current implementation of the UDC works in an RCP environment. Future planned enhancements include a UDC that will run unmodified in a RAP environment.

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

	\chapter{Tool Usability}

	\section{EPP Packaging}

	With millions of downloads in the last 2 years, packages generated by EPP have been proven stable.

	The EPP packages are available from the main eclipse.org download page and all community packages from a Drupal driven site.

	\section{EPP Usage Data Collector}

	More than 120.000 users of the Ganymede Packages already send their UDC data to the Eclipse Foundation every month. The results are available from the Eclipse Foundation web pages \\ (http://www.eclipse.org/org/usagedata/).


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

	\chapter{End-of-Life}

	The EPP packaging application cannot be supported any more. The project uses now existing technology from Equinox p2.

	\chapter{Bugzilla}

	As of 2009-06-01 there are $347$ bugs in technology/epp, $126$ listed with status new, assigned, open. There are no blockers, 5 critical bugs. In the end, there will be no blockers left and all critical bugs for 1.1.0 will be fixed until the release.

	\chapter{Standards}

	\begin{itemize}
	\item EPP uses Java 1.5, compatible with Eclipse 3.4 and 3.5.
	\end{itemize}

	\chapter{UI Usability}

	Only the EPP UDC contains UI elements in form of preferences pages.

	\begin{itemize}
	\item Following Eclipse UI usability guidelines
	\item Usability changes based on users' feedback
	\end{itemize}

	%Summarize the user interface usability and the conformance to the Eclipse User Interface Guidelines. Include section 508 compliance, language pack conformance (does the code support multiple languages), etc. Explain any deviations from the user interface guidelines and standards.
	%Reason: The user community is larger than just mouse-wielding, English-speaking, computer jockeys. We need to support that larger community.

	\chapter{Schedule}

	The plan of the Eclipse Packaging Project is always in parallel with the release train plans, i.e. the Galileo release train (http://www.eclipse.org/projects/project-plan.php?projectid=technology.packaging).

	The scheduled dates for the Ganymede release have been met and the packages were released together with the Ganymede Release in June 2008. Updates have been created and made available for all Ganymede Service Releases.

	For the Galileo release, EPP started to deliver initial packages for Galileo M6, and provided regular package builds based on the new build system with Galileo M7. Since then, EPP delivers all packages for each of the Galileo milestones and release candidates.

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

	\chapter{Communities}

	\begin{itemize}
	\item Active committers (6) and contributors from 4 partners (EclipseSource Inc., Eclipse Foundation, Cloudsmith Inc., Instantiations, Xored)
	\item Participation (Talks) at Eclipse events (EclipseSummit 2008, Eclipse\-Con 2009)
	\item Public conference calls
	\item Developer mailing list with about 630 e-mails, newsgroup with more than 200 messages
	\item The Eclipse Packaging Project has been mentioned in many blog postings, other mailing lists (e.g. cross-project-issues-dev)
	\item Participation in the Eclipse Planning Council and in the Eclipse Architecture Council
	\end{itemize}


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

	\chapter{IP Issues}

	See IP Log at http://www.eclipse.org/projects/ip\_log.php?projectid=technology.packaging

	\begin{itemize}
	\item Initial code contribution got IP clearance from Eclipse Legal (bug 244666)
	\item External contributions are listed in the IP Log and were submitted via Bugzilla
	\end{itemize}

	List of committers:

	\begin{itemize}
	\item Wayne Beaton - committer since 12/2007
	\item Henrik Lindberg - committer since 06/2008
	\item Jordi Böhme López - committer since 06/2008
	\item Alexander Kazantsev, initial committer
	\item Markus Knauer, initial committer
	\item Jeff McAffer - committer since 06/2008
	\item Dan Rubel, initial committer
	\item Mark Russell, initial committer
	\end{itemize}

	Committer emeritus (committers who have been removed from the list of EPP committers during the last 12 months):

	\begin{itemize}
	\item Elias Volanakis, initial committer
	\item Leif Frenzel, initial committer
	\end{itemize}

	%As per the Eclipse IP Policy, these steps must be done:
	% 1. 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.
	% * ... that all significant contributions have been reviewed by the Foundation's legal staff. Include references to the IPZilla numbers of all clearances.
	% * ... that all non-Committer code contributions, including third-party libraries, have been documented in the release and reviewed by the Foundation's legal staff. Include references to the IPZilla numbers of all clearances.
	% * ... that all Contribution Questionnaires have been completed
	% * ... the "provider" field of each feature is set to "Eclipse.org"
	% * ... the "copyright" field of each feature is set to the copyright owner (the Eclipse Foundation is rarely 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.
	% 2. The PMC provides a Project Log that enumerates:
	% 1. every piece of third party software including information on the license
	% 2. every major contribution
	% 3. the name of every contributor including non-committer contributions via bug fixes with bug number's
	% 4. the About files which contain any non-standard terms (e.g., a reference to a license other than the EPL, etc)
	% 3. The EMO will validate for (a) and (b) that Contribution Questionnaires have been properly submitted and EMO approvals have been completed.
	% 4. 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 docuware or as a separate document.

	\chapter{Project Plan}

	Version 1.1.1 is scheduled for October 2009 (Galileo SR1) and will contain mainly bugfixes.

	A detailed plan is not yet available.

	\end{document}