Skip to main content

TM Committer Guidelines

While we do not want to get too process-heavy, there are a few simple things that will make all our lives easier. See also the committer HOWTO for simple cookbook-style instructions for common tasks.

Bugzilla Guidelines

  • See the Bug Process Page for bugzilla queries to find interesting bugs, and our general bug process (handling bugzilla states and priorities)

  • When you check in a fix for a bugzilla entry, please include the bugzilla number in the commit message. Example: "[139207] Fix browsing into tar archives by dstore".

  • After committing a fix for bugzilla, set the entry FIXED. Do not set it closed until it has been tested and verified by somebody else.

Checkin Policies

IP Due Diligence

When you check in a contributed patch, we have to follow IP Due Diligence guidelines, as outlined on the Eclipse IP Process Flowchart and the Project Log Guidelines:

  • Check the contribution. In case of any uncertainty, consult the TM Lead, or Eclipse Legal:

    • Does the contributor have sufficient rights to contribute? In other words, is it written by the contributor himself without referencing any 3rd party materials?
    • Does the contribution include anything not under EPL, or amount to > 250 lines of code including all documentation etc.? If yes, a Contribution Questionnaire has to be filled out! (The 250 line clause can be waived if the contributor is a committer himeself, and there is a member committer agreement in place for his employer company; it may also be waived for plain bug fixes).

  • Add the “www-tm-development” project to your workspace. You can do this most easily by importing the Team Project set from

    In the www-tm project, add a line for the contribution in the tm-log.csv file. There are some sample lines already, so adding one should not be too hard.

  • Before committing both the code changes and the tm-log.csv, for any files patched by the contribution, add a credit line for the contributor into the file’s copyright notice. It’s good practice to give credit to our contributors. (when a whole new file is added by the contribution, leave the copyright notice as is, of course).

  • Make sure the bugzilla number is part of the commit message.

  • For more details, see the Committer Howto on applying a patch from an external contributor .

Coding Guidelines

We do not want to be too restrictive right now - especially do not rewrite existing code just to make it conform to some naming convention. Most of the RSE code seems to follow proper coding style already. In the end, we’ll want to produce code and APIs of Eclipse Quality. Therefore, we better strive for quality early. Which means, try to follow common accepted guidelines for writing new code

Some useful references are

Other stuff for reference

The Eclipse Standard Charter (as referenced by the Tools Project Charter) has more information about committer rights and duties, and our development process.

In particular, this charter says that committers need to agree on the project plan and its modifications, and that committers can veto code changes.

Back to the top