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.
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.
We use the Git version control system
to support concurrent distributed development. All Eclipse project development
is carried out in these repositories:
The repositories support "ssh", "git", and "http"
connection methods. For more information on usage of Git at eclipse.org,
see the Eclipsepedia Git page.
Eclipse uses mailing lists for development coordination, design discussions,
voting, announcements etc.
Eclipse IP Logs
Intellectual property logs, including list of committers, contributors, and
third party code dependencies.
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
API First (pdf)
Best practices for API development based, EclipseCON 2005 presentation by
Jim des Rivieres
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.