doc/releaseReview.1.3.0/epp_1.3.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.3.0}
 \def\everypagetitle{\textbf{Eclipse Technology Project: EPP\\Release Review
 Version 1.3.0}} \def\pubdate{\today}
 \def\workpackage{}
 \def\partners{}
 \def\leadpartner{}
 \def\configid{}
 \def\docclassification{\copyright 2010 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.3.0 EPP release is scheduled for
 2010-06-23 together with the simultaneous release of Helios.}

 \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 for PHP Developers, Eclipse Modeling Tools,
  Eclipse IDE for Java and Report Developers, and Pulsar for Mobile Java
  Developers. Package changes this year:
  \begin{itemize}
    \item Eclipse for RCP/Plug-in Developers has been renamed to Eclipse for RCP
    and RAP Developers and contains new and modified content.
    \item Eclipse Modeling Tools has a reduced content.
    \item Eclipse IDE for JavaScript Web Developers is a new package.
    \item Eclipse IDE for Linux Developers is a new pakage.
  \end{itemize}
  The Helios EPP packages are provided for the following architecture, platform,
  and windowing system combinations:
  \begin{enumerate}
    \item Windows 32-Bit, x86
    \item Windows 64-Bit, x86\_64
    \item Linux 32-Bit, x86, GTK
    \item Linux 64-Bit, x86\_64, GTK
    \item Mac OS-X, 32-Bit, Carbon
    \item Mac OS-X, 32-Bit, Cocoa
    \item Mac OS-X, 64-Bit, Cocoa
  \end{enumerate}
  \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 Integrate the EPP Marketplace Client.} The Eclipse Marketplace
  Client from the EPP MPC project is included in all packages.
 % \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 simultaneous releases (Europa, Ganymede,
  Galileo, Helios).
 \end{itemize}

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

 \chapter{Features}

 EPP for Helios in version 1.3.0 includes

 \begin{itemize}
   \item Buckminster build that generates 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}

 In Galileo, these components had different version numbers, i.e. the EPP UDC had a 1.1 version number, whereas the EPP packages and their definition had a 1.2. In Helios this has been changed and all components delivered by the main EPP project are using the 1.3 version number.

 \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 not been changed since the
 Galileo release. The technology that was used before the Galieo release
 was build on top of the Eclipse update manager technology. Since this technology is
 deprecated and Helios relies on the usage of the 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 and product build.

 \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}

 Both jobs are running on the Hudson continuous integration server provided by
 the Eclipse Foundation.

 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 100.000 new users of the Packages are sending their UDC
 data to the Eclipse Foundation every month. More than 200.000 distinct users
 are uploading their data 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 2010-05-27 there are $483$ bugs in technology/epp, $159$ listed with
 status new, assigned, open. Currently there are no blockers, 5 critical bugs.

 \chapter{Standards}

 \begin{itemize}
   \item The EPP UDC uses Java 1.5, compatible with Eclipse 3.4, 3.5, and 3.6.
   \item The EPP packages use Java 1.5 and are based on Eclipse 3.6.
  \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 sync with the release train plans, i.e. the Helios release train (http://www.eclipse.org/projects/project-plan.php?projectid=technology.packaging).

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

 For the Helios release, EPP started to deliver initial packages for Helios M2, and provided nightly package builds. Since then, EPP delivers all packages for each of the Helios 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 2009, Eclipse\-Con 2010)
   \item Developer mailing list with about 1000 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
   \item No significant changes for Helios
 \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 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 Dan Rubel, 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.3.1 is scheduled for October 2010 (Helios SR1), verion 1.3.2 is scheduled together with Helios SR2. Both will contain mainly bugfixes and no new functionallity.

 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.3.0}
	\def\everypagetitle{\textbf{Eclipse Technology Project: EPP\\Release Review
	Version 1.3.0}} \def\pubdate{\today}
	\def\workpackage{}
	\def\partners{}
	\def\leadpartner{}
	\def\configid{}
	\def\docclassification{\copyright 2010 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.3.0 EPP release is scheduled for
	2010-06-23 together with the simultaneous release of Helios.}

	\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 for PHP Developers, Eclipse Modeling Tools,
	Eclipse IDE for Java and Report Developers, and Pulsar for Mobile Java
	Developers. Package changes this year:
	\begin{itemize}
	\item Eclipse for RCP/Plug-in Developers has been renamed to Eclipse for RCP
	and RAP Developers and contains new and modified content.
	\item Eclipse Modeling Tools has a reduced content.
	\item Eclipse IDE for JavaScript Web Developers is a new package.
	\item Eclipse IDE for Linux Developers is a new pakage.
	\end{itemize}
	The Helios EPP packages are provided for the following architecture, platform,
	and windowing system combinations:
	\begin{enumerate}
	\item Windows 32-Bit, x86
	\item Windows 64-Bit, x86\_64
	\item Linux 32-Bit, x86, GTK
	\item Linux 64-Bit, x86\_64, GTK
	\item Mac OS-X, 32-Bit, Carbon
	\item Mac OS-X, 32-Bit, Cocoa
	\item Mac OS-X, 64-Bit, Cocoa
	\end{enumerate}
	\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 Integrate the EPP Marketplace Client.} The Eclipse Marketplace
	Client from the EPP MPC project is included in all packages.
	% \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 simultaneous releases (Europa, Ganymede,
	Galileo, Helios).
	\end{itemize}

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

	\chapter{Features}

	EPP for Helios in version 1.3.0 includes

	\begin{itemize}
	\item Buckminster build that generates 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}

	In Galileo, these components had different version numbers, i.e. the EPP UDC had a 1.1 version number, whereas the EPP packages and their definition had a 1.2. In Helios this has been changed and all components delivered by the main EPP project are using the 1.3 version number.

	\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 not been changed since the
	Galileo release. The technology that was used before the Galieo release
	was build on top of the Eclipse update manager technology. Since this technology is
	deprecated and Helios relies on the usage of the 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 and product build.

	\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}

	Both jobs are running on the Hudson continuous integration server provided by
	the Eclipse Foundation.

	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 100.000 new users of the Packages are sending their UDC
	data to the Eclipse Foundation every month. More than 200.000 distinct users
	are uploading their data 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 2010-05-27 there are $483$ bugs in technology/epp, $159$ listed with
	status new, assigned, open. Currently there are no blockers, 5 critical bugs.

	\chapter{Standards}

	\begin{itemize}
	\item The EPP UDC uses Java 1.5, compatible with Eclipse 3.4, 3.5, and 3.6.
	\item The EPP packages use Java 1.5 and are based on Eclipse 3.6.
	\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 sync with the release train plans, i.e. the Helios release train (http://www.eclipse.org/projects/project-plan.php?projectid=technology.packaging).

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

	For the Helios release, EPP started to deliver initial packages for Helios M2, and provided nightly package builds. Since then, EPP delivers all packages for each of the Helios 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 2009, Eclipse\-Con 2010)
	\item Developer mailing list with about 1000 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
	\item No significant changes for Helios
	\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 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 Dan Rubel, 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.3.1 is scheduled for October 2010 (Helios SR1), verion 1.3.2 is scheduled together with Helios SR2. Both will contain mainly bugfixes and no new functionallity.

	A detailed plan is not yet available.

	\end{document}