Jump to: navigation, search

Difference between revisions of "Tycho/Contributor Guide"

(Using Gerrit)
Line 34: Line 34:
 
=== Using Gerrit ===
 
=== Using Gerrit ===
  
We prefer patches proposed via Gerrit. Everyone with an eclipse bugzilla login can propose a patch.
+
We prefer patches proposed via [https://git.eclipse.org/r/#/q/project:tycho/org.eclipse.tycho+status:open,n,z Gerrit ]. Everyone with an eclipse bugzilla login can propose a patch.
 
See [[Gerrit | how to use the eclipse Gerrit instance ]].
 
See [[Gerrit | how to use the eclipse Gerrit instance ]].
 +
 +
The push URL to be used when proposing patches for tycho is
 +
 +
https://git.eclipse.org/r/p/tycho/org.eclipse.tycho
  
 
In general, also see [[Development Resources#Users: Contributing To A Project]].
 
In general, also see [[Development Resources#Users: Contributing To A Project]].

Revision as of 12:55, 19 April 2012

How to contribute patches to Tycho

First, read Developing Tycho .

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 tycho-dev@eclipse.org and we will help. If the patch is not trivial, make sure you include a 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 output.

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

Commit Message Guidelines

  • The first sentence should be a clear and concise description about the change
  • Enter a newline before providing a more detailed description about the change
  • When you fix a bug then report which bug you fix. The commit message should start with the bug number.
  • 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.

See an example commit message

Commit Granularity

  • Make small commits, as small as reasonable. 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.
  • 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

Using Gerrit

We prefer patches proposed via Gerrit . Everyone with an eclipse bugzilla login can propose a patch. See how to use the eclipse Gerrit instance .

The push URL to be used when proposing patches for tycho is

https://git.eclipse.org/r/p/tycho/org.eclipse.tycho

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

Using Bugzilla

Open a 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 here).

With the contribution, you will have to include answers to the following questions:

  1. Did you author 100% of the content you are contributing?
  2. Who owns the copyright of the contributed content? (This is typically your employer.)
  3. Is the contributed code licensed under the EPL? (You should answer this question by putting a copyright and license header into every new java file.)
  4. 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.