TmL 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 framework".
- 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
- When you add a new plugin, feature or other project to your workspace,
please update the Team Project Sets so that other committers or
CVS users can pick up your new project easily.
Update the Project sets there and commit them to the web page:You can either export a selection as team project set, or edit the
project set manually. For the pserver version, you typically need to replace-all
":extssh:" by ":pserver:".
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
TmL 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).
In the www-tml project, add a line for the contribution in the tml-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 tml-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 TmL code seems to follow proper coding style already. In the
end, well 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
DSDP 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.
