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 Bugzilla)
(Replaced content with "See https://github.com/eclipse/tycho/blob/master/CONTRIBUTING.md")
 
(24 intermediate revisions by 4 users not shown)
Line 1: Line 1:
== How to contribute patches to Tycho ==
+
See https://github.com/eclipse/tycho/blob/master/CONTRIBUTING.md
 
+
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 [mailto:tycho-dev@eclipse.org 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 [http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-its 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 [http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-its/projects projects/]) and then do some assertions on the build output.
+
 
+
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].
+
 
+
=== 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 [http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=713962c047eb048223d711c62bdb418931172890 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.
+
 
+
 
+
=== Patch Format ===
+
 
+
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.
+
 
+
== Contributing the Patch ==
+
 
+
In general, also see [[Development Resources#Users: Contributing To A Project]].
+
 
+
=== Using Bugzilla ===
+
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]).
+
 
+
With the contribution, you will have to include answers to the following questions:
+
 
+
# Did you author 100% of the content you are contributing?
+
# 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.
+
 
+
=== Via Gerrit ===
+
TDB
+
 
+
[[Category:Tycho|Contributor Guide]]
+

Latest revision as of 18:36, 8 April 2021

See https://github.com/eclipse/tycho/blob/master/CONTRIBUTING.md

Back to the top