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/contributing"

< CDT
(Sending Patches)
(Sending Patches)
(25 intermediate revisions by 12 users not shown)
Line 3: Line 3:
 
To make changes to the CDT, whether it be code, docs, JUnits, etc., you will need to send patches to the source stored on eclipse.org. Here is the process for sending patches.
 
To make changes to the CDT, whether it be code, docs, JUnits, etc., you will need to send patches to the source stored on eclipse.org. Here is the process for sending patches.
  
* To fix anything in CDT first you need to create or find existing bugzilla report for this particular problem/enhancement
+
* To fix anything in CDT first you need to create or find an existing [https://bugs.eclipse.org/bugs/ bugzilla] report for this particular problem/enhancement
* Check out the code from corresponding branch and apply the fix
+
* Setup your eclipse SDK and check out source code, see [[Getting started with CDT development]] article.
** Create a workspace in Eclipse for your work. Check out the CDT plugins you'd like to work on into it. The plugins are on <tt>dev.eclipse.org</tt>, <tt>/cvsroot/tools</tt> under folder <tt>org.eclipse.cdt/all</tt>. There should be around 40 plugins there that you need to check out. More instruction on how to get started are in [[Getting started with CDT development]] article.
+
* Fix the source code
 
* Comment your changes in the code
 
* Comment your changes in the code
 
* If the changes are significant add your name and company in the contributor list in the file header. For new files you must add copyright header: http://wiki.eclipse.org/CDT/policy#Copyright
 
* If the changes are significant add your name and company in the contributor list in the file header. For new files you must add copyright header: http://wiki.eclipse.org/CDT/policy#Copyright
 
* Follow [[CDT/policy|CDT Guidelines]] for code formating and java warnings/errors
 
* Follow [[CDT/policy|CDT Guidelines]] for code formating and java warnings/errors
 
** Externalize strings (excluding exception arguments, tests and special identifiers)
 
** Externalize strings (excluding exception arguments, tests and special identifiers)
** Check for API errors (you have to setup API tooling)
+
** Check for API errors (you have to setup API tooling, see [[CDT/policy#Using_API_Tooling]])
 
** Code with any of the warnings/errors mentioned in the policy, including strings externalization and API errors will not be accepted.
 
** Code with any of the warnings/errors mentioned in the policy, including strings externalization and API errors will not be accepted.
* To minimize the patch, do not re-format the source code you edited (except changed lines). Do not fix any warnings in the code you are not changing (it is good to fix warnings but it would clutter the patch, you want to solve one problem at a time).
+
* To minimize the change, do not re-format the source code you edited (except changed lines). Do not fix any warnings in the code you are not changing  
* Create a patch "Team->Create Patch" command on changed projects, select Workspace as a scope even when only one file has changed. Ensure that all the modified plugins are included when creating the patch.
+
* If you really want to do formatting or styling (such as converting to Java 8) - create another bug for that and submit a gerrit (it is good to fix warnings but it would clutter the patch, you want to solve one problem at a time).
** If you have new or changed binary files such as icons, attach them separately and indicate where do they go
+
* To speed up process of applying your changes you should create one or more junit tests as well and include it in your change
** Check you patch to make sure you did not add anything irrelevant, such as formatting of other code, etc
+
* Gerrit is now used by the CDT project for contributions, follow the steps [[CDT/git#Using_Gerrit_for_CDT|here]] to submit your changes to Gerrit. Changes will not be accepted via patches in Bugzilla.
** 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
+
** Make sure your commit message references the bugzilla bug, e.g:
** Check size of the patch, if it is more than 250 lines see copyright section below
+
  Bug 12345 fixed that, added this
* Submit patch using an attachment to a bug report
+
* A comment should be added to the bugzilla automatically once you post the change to Gerrit. If not please a new comment containing a link to the Gerrit so that people watching the bug know the a change has been posted for review, for example https://git.eclipse.org/r/#/c/8327/
* Mark attachment as a patch
+
* Check size of the contribution, if it adds more than 1,000 lines see copyright section below
* If previous patches attached to the bug, 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
+
 
* Make sure bug report has a clear reproducible scenario, if not add one  
 
* Make sure bug report has a clear reproducible scenario, if not add one  
* To speed up process of applying your patch you should create one or more junit tests as well and attach as separate patch (or together)
+
* Normally committers are watching new Bugzilla/Gerrit activity and somebody would look at your contribution in a few days
* Normally committees are watching new bugzilla activity and somebody would look at your patch in a few days
+
* If it has not received attention in a week or so, some nagging can help. Send email to mailto:cdt-dev@eclipse.org asking committers to look at the contribution. Continue sending e-mails until somebody would give up and look :)
* If the patch has not received an attention in a week or so, some nagging can help. Send email to mailto:cdt-dev@eclipse.org asking committers to look at the patch. Continue sending e-mails until somebody would give up and look.
+
  
  
Line 33: Line 29:
 
* If you copy GPL code we cannot take it
 
* If you copy GPL code we cannot take it
 
* If you copy EPL code, preserve the original copyright and contributors
 
* If you copy EPL code, preserve the original copyright and contributors
* If your changes are more than 250 lines of code patch has to go through IP review process, unless it can be applied by the committer from the same company as you are. Nobody wants to do it so please avoid it. Try to fix one bug at a time.
+
* If your changes add more than 1,000 lines, the patch has to go through IP review process, unless it can be applied by the committer from the same company as you are (Member committer). IP review is a slow process so please try to avoid it. Try to fix one bug at a time.
** (I assume "lines of code" - they exclude comments, xml and properties files)
+
** The 1,000 lines include code, comments and even whitespace.
  
== Tips ==
+
== Signing your Eclipse Contributor Agreement (ECA) ==
  
* If you are behind a firewall, you can use the proxy server at <tt>eclipse.org</tt> to access the CVS repository using pserver on the <tt>proxy.eclipse.org</tt> and port 80.
+
The ECA is a short document that essentially asks the questions required for each contributions. It is mandatory to electronically sign a ECA before any contributions can be accepted.  To sign your ECA:
 +
 
 +
* Obtain an Eclipse Foundation userid. Anyone who currently uses our Bugzilla or Gerrit systems already has one of those. If they don’t, they need to [https://dev.eclipse.org/site_login/ register].
 +
* Login into the [https://projects.eclipse.org projects portal]. Click on your profile name in the top-right corner then select "View my account".
 +
* On the right side of the page, in the Status section, click “Eclipse Contributor Agreement” then follow the instructions.
 +
* If you use Gerrit you might have to wait about an hour until ECA is available in Gerrit.
  
 
[[Category:CDT]]
 
[[Category:CDT]]

Revision as of 13:53, 10 November 2019

Sending Patches

To make changes to the CDT, whether it be code, docs, JUnits, etc., you will need to send patches to the source stored on eclipse.org. Here is the process for sending patches.

  • To fix anything in CDT first you need to create or find an existing bugzilla report for this particular problem/enhancement
  • Setup your eclipse SDK and check out source code, see Getting started with CDT development article.
  • Fix the source code
  • Comment your changes in the code
  • If the changes are significant add your name and company in the contributor list in the file header. For new files you must add copyright header: http://wiki.eclipse.org/CDT/policy#Copyright
  • Follow CDT Guidelines for code formating and java warnings/errors
    • Externalize strings (excluding exception arguments, tests and special identifiers)
    • Check for API errors (you have to setup API tooling, see CDT/policy#Using_API_Tooling)
    • Code with any of the warnings/errors mentioned in the policy, including strings externalization and API errors will not be accepted.
  • To minimize the change, do not re-format the source code you edited (except changed lines). Do not fix any warnings in the code you are not changing
  • If you really want to do formatting or styling (such as converting to Java 8) - create another bug for that and submit a gerrit (it is good to fix warnings but it would clutter the patch, you want to solve one problem at a time).
  • To speed up process of applying your changes you should create one or more junit tests as well and include it in your change
  • Gerrit is now used by the CDT project for contributions, follow the steps here to submit your changes to Gerrit. Changes will not be accepted via patches in Bugzilla.
    • Make sure your commit message references the bugzilla bug, e.g:
 Bug 12345 fixed that, added this 
  • A comment should be added to the bugzilla automatically once you post the change to Gerrit. If not please a new comment containing a link to the Gerrit so that people watching the bug know the a change has been posted for review, for example https://git.eclipse.org/r/#/c/8327/
  • Check size of the contribution, if it adds more than 1,000 lines see copyright section below
  • Make sure bug report has a clear reproducible scenario, if not add one
  • Normally committers are watching new Bugzilla/Gerrit activity and somebody would look at your contribution in a few days
  • If it has not received attention in a week or so, some nagging can help. Send email to mailto:cdt-dev@eclipse.org asking committers to look at the contribution. Continue sending e-mails until somebody would give up and look :)


One of the fundamental rules that Eclipse follows is the ability to trace back who contributed what code and that the person who contributed it has ownership of the code, or has permission from their employer to contribute the code (since employers tend to own everything you write). To help keep this IP integrity going, please ensure your contributions are "clean".

  • If you copy ANY code or images from somewhere else please clearly state it
  • If you copy GPL code we cannot take it
  • If you copy EPL code, preserve the original copyright and contributors
  • If your changes add more than 1,000 lines, the patch has to go through IP review process, unless it can be applied by the committer from the same company as you are (Member committer). IP review is a slow process so please try to avoid it. Try to fix one bug at a time.
    • The 1,000 lines include code, comments and even whitespace.

Signing your Eclipse Contributor Agreement (ECA)

The ECA is a short document that essentially asks the questions required for each contributions. It is mandatory to electronically sign a ECA before any contributions can be accepted. To sign your ECA:

  • Obtain an Eclipse Foundation userid. Anyone who currently uses our Bugzilla or Gerrit systems already has one of those. If they don’t, they need to register.
  • Login into the projects portal. Click on your profile name in the top-right corner then select "View my account".
  • On the right side of the page, in the Status section, click “Eclipse Contributor Agreement” then follow the instructions.
  • If you use Gerrit you might have to wait about an hour until ECA is available in Gerrit.

Back to the top