Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "CDT/policy"
< CDT
(→Contributing the Patch) |
(→Committing Code) |
||
| Line 82: | Line 82: | ||
* When development reaches cycle where release candidates are built, letter in cdt-dev should be sent for every commit you are making | * 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 <tt>[12345] - fixed bla bla</tt> | * Have a bug associated with every commit, bug number at the begging of commit comment in for of <tt>[12345] - fixed bla bla</tt> | ||
| − | * Have a patch for commit attached to the pr | + | * Have a patch for commit attached to the pr (optional but encouraged) |
* Optional request a reviewer bug setting review flag to ? and flag comment to person address (or inbox) | * Optional request a reviewer bug setting review flag to ? and flag comment to person address (or inbox) | ||
Revision as of 12:58, 2 June 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.
Patches with errors listed above, including API errors would not be accepted.
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
- To fix anything in CDT first you need to create or find existing bugzilla report for this particular problem/enhancement
- Check out the code from corresponding branch and apply the fix
- Comment your changes in the code
- You can also add your contributor company/name in the file header
- Follow CDT guidelines for code formating and java warnings/errors
- To minimize the patch, do not re-format the source code you edited (except changed lines)
- Submit patch using an attachment to a bug report
- Mark attachment as a patch
- Mark attachment with iplog+ flag (unless you are CDT committer, in this case it should be iplog-)
- If previous patches attached to pr, which are obsolete now mark them as such
- Add a comment to which branch the patch should be applied (HEAD by default)
- Add a comment on what patch is doing, it is not easy to figure it out from the code sometimes
- Make sure bug report has a clear reproducible scenario, if not add one
- Send email to mailto:cdt-dev@eclipse.org to notify committers
- If you really want to do formatting or styling (such as converting to java 1.5) - create another bug for that and attach a patch
- To speed up process of applying your patch you should create one or more junit tests as well and attach as separate patch
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 (unless submitted by Commiter) - See also Development_Resources/Automatic_IP_Log
- Check that all non-committed patches marked as obsolite
- Check that all committed patches are marked iplog-
- 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 but encouraged)
- Optional request a reviewer bug setting review flag to ? and flag comment to person address (or inbox)
Version Numbering
See Eclipse Version Numbering Guildlines
Bugs Workflow
For creating and managing bugs see http://wiki.eclipse.org/CDT/Bugs