Difference between revisions of "CDT/contributing"

From Eclipsepedia

< CDT
Jump to: navigation, search
(Sending Patches)
(Merged from police page)
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.
  
# 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>. The plugins are under folder <tt>org.eclipse.cdt/all</tt>. There should be around 40 plugins there that you need to check out.
+
* To fix anything in CDT first you need to create or find existing bugzilla report for this particular problem/enhancement
# Edit and test your change. This is basic Eclipse plugin development. There are a number of resources on the web and in the Eclipse help system on how to do this. Read  [[CDT/policy|CDT Guideline]] for code conventions.
+
* Check out the code from corresponding branch and apply the fix
# Use the Eclipse Team menu to create a patch (click <b>Team > Create Patch</b>). Ensure that all the modified plugins are included when creating the patch. In Eclipse 3.2 and later releases you can create a patch for your whole workspace. For Eclipse 3.1, you will need to create a patch for each plugin you've changed.
+
** 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.
# Attach the patch or patches to a bugzilla entry. Make sure you check off the patch box to help us find patches.
+
* Comment your changes in the code
 +
* If the changes are significant add your name and company in the contributor list in the file header
 +
* Follow [[CDT/policy|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). 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).
 +
* 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.
 +
* Submit patch using an attachment to a bug report
 +
* Mark attachment as a patch
 +
* 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 sometimes
 +
* Make sure bug report has a clear reproducible scenario, if not add one
 +
* 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
 +
* Normally committers are watching new bugzilla activity and somebody would look at your patch in a few days
 +
* 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
 +
 
  
 
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".
 
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 code 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 are more than 150 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
  
 
== Tips ==
 
== Tips ==

Revision as of 21:57, 11 May 2010

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
  • Check out the code from corresponding branch and apply the fix
    • 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 dev.eclipse.org, /cvsroot/tools under folder org.eclipse.cdt/all. There should be around 40 plugins there that you need to check out.
  • Comment your changes in the code
  • If the changes are significant add your name and company in the contributor list 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). 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).
  • 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.
  • Submit patch using an attachment to a bug report
  • Mark attachment as a patch
  • 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 sometimes
  • Make sure bug report has a clear reproducible scenario, if not add one
  • 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
  • Normally committers are watching new bugzilla activity and somebody would look at your patch in a few days
  • 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


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 code 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 are more than 150 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

Tips

  • If you are behind a firewall, you can use the proxy server at eclipse.org to access the CVS repository using pserver on the proxy.eclipse.org and port 80.