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 "Tycho/Contributor Guide"

(Via Gerrit)
m (fix IT link)
(22 intermediate revisions by 4 users not shown)
Line 1: Line 1:
== How to contribute patches to Tycho ==
+
== Starting a Contribution ==
  
First, read [[Developing Tycho]] .
+
Before starting to develop an enhancement or fix for Tycho, it is important that you get in touch with the project. We track ideas for enhancements and bug reports in the [https://bugs.eclipse.org/bugs/query.cgi?format=specific;product=Tycho Eclipse Bugzilla], so this is a good place to present your ideas for a patch and to make sure it's going in the right direction.
  
If you want to do an enhancement but don't know where to start or if it's going in the right direction, just ask on [mailto:tycho-dev@eclipse.org tycho-dev@eclipse.org] and we will help.
+
If you want to do a contribution but don't know where to start, you should to check the [https://bugs.eclipse.org/bugs/buglist.cgi?classification=Technology&product=Tycho&keywords=helpwanted&resolution=--- open bugs tagged with keyword "helpwanted"]. These are bugs with moderate complexity and estimated effort. In case of questions related to a contribution, you can also just ask on [mailto:tycho-dev@eclipse.org tycho-dev@eclipse.org].
If the patch is not trivial, make sure you include a test case that reproduces the bug or proves that the enhancement works.
+
 
 +
== Developing Patches for Tycho ==
 +
 
 +
The technical basics (how to get the sources, how to import and build, etc.) are described here: [[Developing Tycho]] .
 +
 
 +
Unless the patch is really trivial, make sure you include at least one test case that reproduces the bug or proves that the enhancement works.
  
 
=== Writing Tests ===
 
=== Writing Tests ===
Line 10: Line 15:
  
 
Unit tests are preferred if possible because they are in general much faster and better targeted at the functionality under test.
 
Unit tests are preferred if possible because they are in general much faster and better targeted at the functionality under test.
Integration tests generally invoke a forked maven build on a sample project (stored under [http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-its/projects projects/]) and then do some assertions on the build output.
+
Integration tests generally invoke a forked Maven build on a sample project (stored under [http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-its/projects projects/]) and then do some assertions on the build results.
  
See an example for a  [http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-core/src/test/java/org/eclipse/tycho/core/locking/FileLockServiceTest.java unit test] and an [http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-its/src/test/java/org/eclipse/tycho/test/featurePatch/external/EclipseRepoIncludingFeaturePatchTest.java integration test].
+
See an example for a  [http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-core/src/test/java/org/eclipse/tycho/core/locking/FileLockServiceTest.java unit test] and an [http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-its/src/test/java/org/eclipse/tycho/test/featurePatch/EclipseRepoIncludingFeaturePatchTest.java integration test].
  
 
=== Commit Message Guidelines ===
 
=== Commit Message Guidelines ===
  
* The first sentence should be a clear and concise description about the change
+
* Start with "Bug: <number>" stating the bug number the change is related to; this will enable the eclipse genie bot to automatically cross-link bug and gerrit proposal
* Enter a newline before providing a more detailed description about the change
+
* Also in the first line, provide a clear and concise description of the change
* When you fix a bug then report which bug you fix. The commit message should start with the bug number.
+
* Add one blank line, followed by more details about the change. This could include a motivation for the change and/or reasons why things were done in the particular way they are done in the change.
* When there are deeper reasons for doing things the way the commit does, then explain these as well. This all is for the reviewers and yourself: the context of the commit is completely clear.
+
* Add "Signed-off-by: <your_email_adress>" in the footer (see "Legal Paperwork" below).
 +
 
 +
See an [http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=309fbd05d46510671218ef2863885b48a12d8451 example commit message]
  
See an [http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=713962c047eb048223d711c62bdb418931172890 example commit message]
 
 
 
=== Commit Granularity ===
 
=== Commit Granularity ===
  
* Make small commits, as small as reasonable. This makes them easy to review.
+
* Make small commits, yet self-contained commits. This makes them easy to review.
 
* Do not mix concerns in commits: have a commit do a single thing. This makes them reviewable 'in isolation'. This is particularly important if you need to do refactorings to the existing code: Refactorings tend to lead to large diffs which are difficult to review. Therefore make sure to have separate commits for refactorings and for functional changes.
 
* Do not mix concerns in commits: have a commit do a single thing. This makes them reviewable 'in isolation'. This is particularly important if you need to do refactorings to the existing code: Refactorings tend to lead to large diffs which are difficult to review. Therefore make sure to have separate commits for refactorings and for functional changes.
* Split your work into multiple smaller pieces of work (when possible) and implement each of these pieces in a series of commits.
 
  
 +
== Contributing the Patch ==
  
=== Patch Format ===
+
=== Legal Paperwork ===
  
We prefer git patches created with [http://schacon.github.com/git/user-manual.html#submitting-patches git format-patch] since they include a commit message and preserve author information. This will also give you the credit you deserve in the git history.
+
Before your contribution can be accepted by the project, you need to create and
 +
[[Development Resources/Contributing via Git#Eclipse_Foundation_Contributor_License_Agreement | electronically sign the Eclipse Foundation Contributor License Agreement (CLA)]and sign
 +
off on the Eclipse Foundation Certificate of Origin.  
  
== Contributing the Patch ==
+
Follow the instructions on [[Development_Resources/Handling Git Contributions]]
  
 
In general, also see [[Development Resources#Users: Contributing To A Project]].
 
In general, also see [[Development Resources#Users: Contributing To A Project]].
  
=== Using Bugzilla ===
+
=== Pushing to Gerrit ===
Open a [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Tycho&rep_platform=All&op_sys=All bug] and attach the patch, or provide the URLs of the commit(s) you want to contribute in a comment to the bug. (Details for the latter option can be found [http://wiki.eclipse.org/Development_Resources/Handling_Git_Contributions here]).
+
 
 +
The [https://git.eclipse.org/r/#/q/project:tycho/org.eclipse.tycho+status:open,n,z Eclipse Gerrit] is the preferred way to propose patches to Tycho. Everyone with an Eclipse Bugzilla login can propose patches.
  
With the contribution, you will have to include answers to the following questions:
+
In order to propose a change to Tycho
 +
* Configure the repository URL <tt>https:</tt><tt>//git.eclipse.org/r/tycho/org.eclipse.tycho</tt> for the remote "origin"
 +
* Know your [https://git.eclipse.org/r/#/settings/http-password Gerrit HTTPS user name and password]
 +
* Push to the special code review branch "refs/for/master", e.g. with <tt>git push origin HEAD:refs/for/master</tt>
  
# Did you author 100% of the content you are contributing?
+
For more information on the Eclipse Gerrit instance (e.g. how to push via SSH), see here: [[Gerrit]].
# Who owns the copyright of the contributed content? (This is typically your employer.)
+
# Is the contributed code licensed under the EPL? (You should answer this question by putting a [http://www.eclipse.org/legal/copyrightandlicensenotice.php copyright and license header] into every new java file.)
+
# Do you have the right to contribute the content to Eclipse? (You need to confirm this with the copyright owner.)
+
  
With these questions answered, we will be able to accept small patches (<250 LoC) immediately. For larger patches, we will also have to create a contribution questionnaire for review by the Eclipse IP team, but this usually doesn't require additional actions from you.
+
Note that prototypes and other incomplete work should be clearly marked as such e.g. by adding "POC" or "WIP" in the commit message, by commenting in Gerrit, or by pushing to the refs/for/master/POC topic branch. This avoids that committers spend time on reviewing incomplete changes.
  
=== Using Gerrit ===
 
TDB
 
  
 
[[Category:Tycho|Contributor Guide]]
 
[[Category:Tycho|Contributor Guide]]
 +
[[Category:How to Contribute]]

Revision as of 04:46, 12 December 2016

Starting a Contribution

Before starting to develop an enhancement or fix for Tycho, it is important that you get in touch with the project. We track ideas for enhancements and bug reports in the Eclipse Bugzilla, so this is a good place to present your ideas for a patch and to make sure it's going in the right direction.

If you want to do a contribution but don't know where to start, you should to check the open bugs tagged with keyword "helpwanted". These are bugs with moderate complexity and estimated effort. In case of questions related to a contribution, you can also just ask on tycho-dev@eclipse.org.

Developing Patches for Tycho

The technical basics (how to get the sources, how to import and build, etc.) are described here: Developing Tycho .

Unless the patch is really trivial, make sure you include at least one test case that reproduces the bug or proves that the enhancement works.

Writing Tests

Tycho has two types of tests: unit tests (locally in each module) and a global integration test suite in module tycho-its.

Unit tests are preferred if possible because they are in general much faster and better targeted at the functionality under test. Integration tests generally invoke a forked Maven build on a sample project (stored under projects/) and then do some assertions on the build results.

See an example for a unit test and an integration test.

Commit Message Guidelines

  • Start with "Bug: <number>" stating the bug number the change is related to; this will enable the eclipse genie bot to automatically cross-link bug and gerrit proposal
  • Also in the first line, provide a clear and concise description of the change
  • Add one blank line, followed by more details about the change. This could include a motivation for the change and/or reasons why things were done in the particular way they are done in the change.
  • Add "Signed-off-by: <your_email_adress>" in the footer (see "Legal Paperwork" below).

See an example commit message

Commit Granularity

  • Make small commits, yet self-contained commits. This makes them easy to review.
  • Do not mix concerns in commits: have a commit do a single thing. This makes them reviewable 'in isolation'. This is particularly important if you need to do refactorings to the existing code: Refactorings tend to lead to large diffs which are difficult to review. Therefore make sure to have separate commits for refactorings and for functional changes.

Contributing the Patch

Legal Paperwork

Before your contribution can be accepted by the project, you need to create and electronically sign the Eclipse Foundation Contributor License Agreement (CLA) and sign off on the Eclipse Foundation Certificate of Origin.

Follow the instructions on Development_Resources/Handling Git Contributions

In general, also see Development Resources#Users: Contributing To A Project.

Pushing to Gerrit

The Eclipse Gerrit is the preferred way to propose patches to Tycho. Everyone with an Eclipse Bugzilla login can propose patches.

In order to propose a change to Tycho

  • Configure the repository URL https://git.eclipse.org/r/tycho/org.eclipse.tycho for the remote "origin"
  • Know your Gerrit HTTPS user name and password
  • Push to the special code review branch "refs/for/master", e.g. with git push origin HEAD:refs/for/master

For more information on the Eclipse Gerrit instance (e.g. how to push via SSH), see here: Gerrit.

Note that prototypes and other incomplete work should be clearly marked as such e.g. by adding "POC" or "WIP" in the commit message, by commenting in Gerrit, or by pushing to the refs/for/master/POC topic branch. This avoids that committers spend time on reviewing incomplete changes.

Back to the top