From Ian in the committer list. There might be some input needed here
from p2 if we are going to produce installers etc.
Dear Eclipse Committers
We would like to encourage more participation in the creation of the
packages created by the Eclipse Packaging Project. The goal is to 1)
encourage more cross-project testing of the existing four packages, and
2) encourage the creation of packages in addition to the existing four
that were created last year. A framework for doing this was discussed at
a recent Planning Council meeting
and this document is to provide addition details.
1. Creation of a Package
To create a package a project leader or committer must agree to be a
package maintainer. The package maintainer is responsible for defining
the contents of the package and arrange for testing of the package.
To define a package the package maintainer will need to specify the
package contents based on the EPP package configuration file format
<http://wiki.eclipse.org/EPP/Configuration_File_Format>. The package
maintainer will need to store this file in their cvs repository and then
inform the EPP team, via a bugzilla entry, the location of the file. The
EPP team will then begin to automatically build the package based on the
2. What can be included in a Package?
· Packages must only contain code from Eclipse projects
· Packages should usually only contain code from projects that have
passed their 1.0 creation review, and if exceptions are found, the code
must still have passed an Eclipse Release Review.
· Packages should attempt to include code from a variety of projects,
while maintaining a coherent theme to the package, balanced with
download and install size, fitting with the desires and suggestions of
3. Testing of a Package
The package maintainer is responsible for testing the package. The
package maintainer should arrange for a number of committers and
community members to act as testers. The type and degree of testing may
vary but is expected to at least confirm that all the projects basically
work together with no immediate problems introduced by being packaged
together. In all cases the type of testing and test cases should be
documented. EPP will define a process for each package maintainer to
identify that the package has been tested, the type of testing and that
the package is ready for download.
4. Publishing of Packages
A new web site will be created to publish the different packages. This
new web site will be directly accessible from the download page. The
packaging page will show all the available packages and use social
networking techniques to influence the order and display of the
packages. For instance, the number of time a package is download will be
visible, the names of the project maintainers and testers will be
associated with the project or maybe individuals can vote/recommend a
package. The Eclipse Foundation will also continue to list 4-5 packages
directly on the download page.
How to Get Started?
If you would like to create a package, we ask that you open a bugzilla
request for EPP, using the ‘package content’ component. In the bugzilla
bug, please specify a description of the package you would like to
create, including the intended targeted user and the feature set of the
package. You will then need to create a package configuration file
together with the EPP team and then specify the location of the file.
You will then need to create an package configuration file and then
specify the location of the file. Please add this location to the
bugzilla request. EPP builds the packages on a nightly basis, so once
your package is defined, we will start building it.
EPP is also releasing packages for each milestone and release candidate
for Ganymede. If you would like your package to be built for M5, we ask
that you please have it defined before February 11.
We are just starting this process so your feedback and support is
welcome. It will take sometime to make it perfect but the intention is
to have a number of packages available in time for the Ganymede release.
Thanks for your support,
Director of Marketing
613-224-9461 ext. 227
blog: ianskerrett.wordpress.com <.wordpress>
equinox-dev mailing list