Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "DSDP/MTJ/Proposal for Code Checkin"
(Initial data) |
|||
(2 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
− | In addition to all of the requirements for code checkin in the Eclipse process [http://wiki.eclipse.org/index.php/Development_Conventions_and_Guidelines] we should follow the following addtional guidelines. | + | In addition to all of the requirements for code checkin in the Eclipse process [http://wiki.eclipse.org/index.php/Development_Conventions_and_Guidelines Development Conventions and Guidelines] we should follow the following addtional guidelines. |
− | # All code checkins should have a bug as a reference for the code change. An exception for small spelling or formatting changes is allowed. | + | # All code checkins should have a bug as a reference for the code change. |
+ | ## Each bug should adress a single concept. | ||
+ | ## A bug can have multiple checkins to address the issue. | ||
+ | ## An exception for small spelling or formatting changes is allowed. | ||
# All checkins should have comments attached to the checkin when it is committed to the CVS archive. | # All checkins should have comments attached to the checkin when it is committed to the CVS archive. | ||
− | # All checkins should include the bug number at the beginning of the checkin comment. For example, prefix the comment with "Bug xxxxx | + | ## All checkins should include the bug number at the beginning of the checkin comment. For example, prefix the comment with "Bug xxxxx: " |
+ | ## The comment should describe the changes. | ||
+ | ## The comment should not say 'small change', 'sync code', or something similar. | ||
+ | # All files modified should have their copyright statements updated, if necessary. | ||
+ | ## If the file has not been checked in this year, there should be a year update. | ||
+ | ## If desired, the additional contributors line should be updated. | ||
+ | ## If the copyright has a single entity, and you are not from that entity, you should add the line 'and others' to the copyright statement. | ||
+ | # All code should be checked to make sure that it has been localized and internationalized using the 'external strings' selection in the IDE. | ||
+ | ## Any new plug-ins should conform to the Eclipse legal requirements, such as having an about.html. | ||
− | Look at [http://www.eclipse.org/dsdp/tm/development/committer_howto.php] | + | Look at [http://www.eclipse.org/dsdp/tm/development/committer_howto.php TM Project Committer How To Checkin] |
Latest revision as of 12:27, 27 May 2008
In addition to all of the requirements for code checkin in the Eclipse process Development Conventions and Guidelines we should follow the following addtional guidelines.
- All code checkins should have a bug as a reference for the code change.
- Each bug should adress a single concept.
- A bug can have multiple checkins to address the issue.
- An exception for small spelling or formatting changes is allowed.
- All checkins should have comments attached to the checkin when it is committed to the CVS archive.
- All checkins should include the bug number at the beginning of the checkin comment. For example, prefix the comment with "Bug xxxxx: "
- The comment should describe the changes.
- The comment should not say 'small change', 'sync code', or something similar.
- All files modified should have their copyright statements updated, if necessary.
- If the file has not been checked in this year, there should be a year update.
- If desired, the additional contributors line should be updated.
- If the copyright has a single entity, and you are not from that entity, you should add the line 'and others' to the copyright statement.
- All code should be checked to make sure that it has been localized and internationalized using the 'external strings' selection in the IDE.
- Any new plug-ins should conform to the Eclipse legal requirements, such as having an about.html.