Development Process

Conventions and Guidelines
Look here for the for the coding standards, naming conventions, and other
guidelines we use to help ensure eclipse presents to users and developers
as a unified whole rather than as a loose collection of parts.

Bug Reports
Eclipse uses Bugzilla
as our bug tracking system. Bugzilla has a wide following within the open
source community and directly supports the workflows associated with distributed
development (e.g., email notification). You can sign up for your own Eclipse
bugzilla ID and start contributing bug reports.

Git Repositories
We use the Git version control system
to support concurrent distributed development. All Eclipse project development
is carried out in these repositories:

Eclipse IP Logs
Intellectual property logs, including list of committers, contributors, and
third party code dependencies.

Porting Guides
Eclipse project porting guides detail incompatible API changes,
and recommended client changes in each release. For each change
there is a summary of what clients are affected, and steps for clients
to migrate.

API First (pdf)
Best practices for API development based, EclipseCON 2005 presentation by
Jim des Rivieres

Eclipse Performance
Poor performance is a bug and should be tested for, tracked and fixed in
the same way. The Eclipse Performance page is a collection of resources
and information aimed at helping plug-in developers do just that.

Eclipse 2.0 Retrospective Actions
In August 2002 retrospective sessions were held with the various
component teams to discuss what worked (and didn't work) with the 2.0 release.
Based on the feedback collected during these sessions, we agreed on actions for the 2.1 effort.