Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "SWT/Devel/Gtk/Patch guidelines"
(Created page with "= Patch submission guidelines = When submitting patches, you should consider the following: == Formatting == Your patches must: * Avoid re-factoring code in the same patch as...") |
(→Patch submission guidelines) |
||
(3 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
= Patch submission guidelines = | = Patch submission guidelines = | ||
− | When submitting patches, you should consider the following | + | When submitting patches, you should consider the following guidelines. |
== Formatting == | == Formatting == | ||
− | + | * Avoid re-factoring code in the same patch as a bug-fix. Instead split it up into two commits. This makes it easier to rollback broken commits and avoids merge conflicts. | |
− | * Avoid re-factoring code in the same patch as a bug-fix. Instead split it up into two commits. | + | * Please avoid removing white spaces in the same commit as a bug fix. Reviewing patches that consist of a lot of white space removal and a few actual code changes is tedious and causes merge conflicts. Instead submit white space removal in a separate patch. |
− | + | ||
− | * Please avoid removing white spaces in the same commit as a bug fix. | + | |
* Do not introduce any trailing white space into the code base. | * Do not introduce any trailing white space into the code base. | ||
− | * Your code should follow SWT code style. See the code in other widgets for guidance. | + | * Your code should follow SWT code style. See the code in other widgets for guidance. E.g use '!=' instead of '>' for bit checks. |
* Avoid introducing methods that are only called once. But if you see the same code many times, it makes sense to add a method for it. | * Avoid introducing methods that are only called once. But if you see the same code many times, it makes sense to add a method for it. | ||
* When removing code that calls internal functions, check that those functions are actually still called else where. Avoid leaving dead methods in the code. | * When removing code that calls internal functions, check that those functions are actually still called else where. Avoid leaving dead methods in the code. | ||
− | * Not contain non-ASCII characters | + | * [[SWT/Devel/Gtk/NonAsciiCharacters | Not contain non-ASCII characters]] |
+ | * Refer to the [[SWT/Devel/Style | style guidelines]] for information regarding commit message etiquette | ||
== Building/Compiling == | == Building/Compiling == | ||
Line 18: | Line 17: | ||
== Testing == | == Testing == | ||
− | * Any testing should happen across | + | * Any testing should happen across the last two stable versions of GTK3, GTK3.22 and GTK3.24. GTK2 testing isn't required as it will be removed in Eclipse 4.10. Please see the [[SWT/Devel/Gtk/JUnitTests | JUnit testing page]] for more info. |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
* If the initial bug report contains a snippet that reproduces the issue, please test using this snippet as well | * If the initial bug report contains a snippet that reproduces the issue, please test using this snippet as well | ||
− | * Please run the JUnit test suites on your patch | + | * Please run the JUnit test suites on your patch, and try a child Eclipse instance to make sure nothing else is broken |
− | + | ||
− | + | ||
− | + | ||
− | + |
Latest revision as of 15:48, 22 August 2018
Patch submission guidelines
When submitting patches, you should consider the following guidelines.
Formatting
- Avoid re-factoring code in the same patch as a bug-fix. Instead split it up into two commits. This makes it easier to rollback broken commits and avoids merge conflicts.
- Please avoid removing white spaces in the same commit as a bug fix. Reviewing patches that consist of a lot of white space removal and a few actual code changes is tedious and causes merge conflicts. Instead submit white space removal in a separate patch.
- Do not introduce any trailing white space into the code base.
- Your code should follow SWT code style. See the code in other widgets for guidance. E.g use '!=' instead of '>' for bit checks.
- Avoid introducing methods that are only called once. But if you see the same code many times, it makes sense to add a method for it.
- When removing code that calls internal functions, check that those functions are actually still called else where. Avoid leaving dead methods in the code.
- Not contain non-ASCII characters
- Refer to the style guidelines for information regarding commit message etiquette
Building/Compiling
- Compile/build on both GTK2 and GTK3
- Be sure to commit all files necessary for native building, i.e. os_stats.h, etc...
Testing
- Any testing should happen across the last two stable versions of GTK3, GTK3.22 and GTK3.24. GTK2 testing isn't required as it will be removed in Eclipse 4.10. Please see the JUnit testing page for more info.
- If the initial bug report contains a snippet that reproduces the issue, please test using this snippet as well
- Please run the JUnit test suites on your patch, and try a child Eclipse instance to make sure nothing else is broken