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 "CDT/policy"
< CDT
m (→Applying the Patch) |
(→Eclipse Java Errors/Warnings) |
||
Line 18: | Line 18: | ||
* Unused Import - Error | * Unused Import - Error | ||
+ | All commiters should enabled API tooling by setting target baseline platform. Do not commit code with API errors. | ||
== Copyright == | == Copyright == |
Revision as of 13:16, 23 February 2009
Contents
Code Formatting
- It is recommended to use default "Eclipse" code formatting for Java for new code.
- It is recommended to preserve formatting of old code when making patches
Eclipse Java Errors/Warnings
It is strongly recommended for cdt project to override default compiler error/warning and use project specific errors/warnings. These errors should be enabled:
- Method with a constructor name - Error
- Assignment has no effect - Error
- Possible accidental boolean assignment - Error
- finally does not complete normally - Error
- Using a char array in string concatenation - Error
- Null pointer access - Error
- Potential null pointer access - Warning
- Unused Import - Error
All commiters should enabled API tooling by setting target baseline platform. Do not commit code with API errors.
Copyright
Use eclipse copyright header: http://www.eclipse.org/legal/copyrightandlicensenotice.php
/******************************************************************************* * Copyright (c) {DATE} {INITIAL COPYRIGHT OWNER} {OTHER COPYRIGHT OWNERS}. * All rights reserved. This program and the accompanying materials * are made available under the terms of the Eclipse Public License v1.0 * which accompanies this distribution, and is available at * http://www.eclipse.org/legal/epl-v10.html * * Contributors: * {INITIAL AUTHOR} - initial API and implementation *******************************************************************************/
Javadoc
All new public classes must have meaningful javadoc header, as well as all public and interface methods and constants.
Contributing the Patch
- Comment your changes in the code
- To minimize the patch, do not re-format the source code you edited
- Submit patch using an attachment to a bug report
- Mark attachment as patch
- Add a comment to which branch the patch should be applied (HEAD by default)
- Send email to mailto:cdt-dev@eclipse.org to notify committers
see also CDT/contributing
Applying the Patch
- Assign bug to yourself
- Set target milestone field to release in which patch would be applied, If it is applied in two branches set target milestone to maintenance branch
- Code inspect the patch, apply and test
- Commit the patch
- Set the iplog+ flag for the committed patch - See also Development_Resources/Automatic_IP_Log
- Change bug state to fixed
- Add a comment about where it was fixed (branches) and related notes
Committing Code
- API changes have to be discussed in cdt-dev mailing list before commiting
- When development reaches cycle where release candidates are built, letter in cdt-dev should be sent for every commit you are making
- Have a bug associated with every commit, bug number at the begging of commit comment in for of [12345] - fixed bla bla
- Have a patch for commit attached to the pr
- Optional request a reviewer bug setting review flag to ? and flag comment to person address (or inbox)