“Wir werden e4 in Helios wiedersehen”, Part Three

In this installment, I bring you the fourth question (#3, zero-based) from my interview in Eclipse Magazin.

3. What is an Eclipse-project obliged to do in order to take part of the Common Release Train, e.g. the Galileo release train?

– Which release processes are necessary? – What are the guidelines for the IP Clearance? – What has to be done regarding documentation, internationalisation and test processes?

The requirements for participation in the release train are very well defined. The Eclipse Planning Council, very early in the development cycle, created a collection of “must dos” and “should dos” for projects that want to participate. The full list is captured on the Galileo Simultaneous Release wiki page.

The first thing that a project that wants to participate in the release train must do is announce their intent to participate. For Galileo, projects were required to state their intention prior to the fourth milestone release on December 12/2008. Perhaps the most important thing, and it’s no coincidence that it tops the list of participation requirements, is communication. In keeping with the communication theme, participating projects where required to have a project plan, participate in several communication channels with other participating projects, and—as always—work in an open and transparent way.

Most of the rules for participation, are really “good neighbour” rules, including such things as guidelines for naming bundles, sharing common third-party libraries through the Orbit project, leveraging features in the platform, testing, and ensuring that the user interface components are properly configured for language translation via the Babel project. The projects participating in Galileo are required to make a release as defined by the Eclipse Development Process. This requires that the project demonstrate IP cleanliness, development of a community and so on.

Some of the participation rules were controversial. One rule states that projects must use only public APIs of the other Eclipse projects they consume. Deviations from this rule have to be explained to the satisfaction of the Eclipse Planning Council and the rest of the Galileo community. Several projects had difficulty with this requirement for various reasons, but all was satisfactorily resolved in time for the release.

See part one and part two of this series.

This entry was posted in Community. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s