Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "CDT/policy"

< CDT
(Committing Code)
(Committing Code)
Line 61: Line 61:
 
* API changes have to be discussed in cdt-dev mailing list before commiting
 
* 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
 
* 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 patch for commit attached to the pr
 +
* Optional request a reviewer bug setting review flag to ? and flag comment to person address (or inbox)
  
 
== Version Numbering ==
 
== Version Numbering ==
  
 
See [[Version_Numbering|Eclipse Version Numbering Guildlines]]
 
See [[Version_Numbering|Eclipse Version Numbering Guildlines]]

Revision as of 15:22, 23 September 2008

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


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
 *******************************************************************************/ 

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-patch@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
  • Add keyword "contributed" to the bug
  • 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)

Version Numbering

See Eclipse Version Numbering Guildlines

Back to the top