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.
Difference between revisions of "SWT/Devel/Gtk/Patch guidelines"
(→Patch submission guidelines) |
(→Patch submission guidelines) |
||
| Line 9: | Line 9: | ||
* 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. | ||
| − | * | + | * [[SWT/Devel/Gtk/NonAsciiCharacters | Not contain non-ASCII characters]] |
* Refer to the [[SWT/Devel/Style | style guidelines]] for information regarding commit message etiquette | * Refer to the [[SWT/Devel/Style | style guidelines]] for information regarding commit message etiquette | ||
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