Patch files can be easily generated from Eclipse, for example by selecting "Team -> Create Patch". Patches can also be created by git diff and svn diff.
Please submit one patch-file per Jira. For example, if multiple files are changed make sure the selected resource when generating the patch is a directory. Patch files can reflect changes in multiple files.
Make sure you review Section 1.2.1.1, “Code Formatting” for code style.
The patch file should have the HBase Jira ticket in the name. For example, if a patch was submitted for Foo.java
, then
a patch file called Foo_HBASE_XXXX.patch
would be acceptable where XXXX is the HBase Jira number.
If you generating from a branch, then including the target branch in the filename is advised, e.g., HBASE-XXXX-0.90.patch
.
Yes, please. Please try to include unit tests with every code patch (and especially new classes and large changes). Make sure unit tests pass locally before submitting the patch.
Also, see Section 1.6.2.1, “Mockito”.
The patch should be attached to the associated Jira ticket "More Actions -> Attach Files". Make sure you click the ASF license inclusion, otherwise the patch can't be considered for inclusion.
Once attached to the ticket, click "Submit Patch" and the status of the ticket will change. Committers will review submitted patches for inclusion into the codebase. Please understand that not every patch may get committed, and that feedback will likely be provided on the patch. Fear not, though, because the HBase community is helpful!
The following items are representative of common patch feedback. Your patch process will go faster if these are taken into account before submission.
See the Java coding standards for more information on coding conventions in Java.
Rather than do this...
if ( foo.equals( bar ) ) { // don't do this
... do this instead...
if (foo.equals(bar)) {
Also, rather than do this...
foo = barArray[ i ]; // don't do this
... do this instead...
foo = barArray[i];
Auto-generated code in Eclipse often looks like this...
public void readFields(DataInput arg0) throws IOException { // don't do this foo = arg0.readUTF(); // don't do this
... do this instead ...
public void readFields(DataInput di) throws IOException { foo = di.readUTF();
See the difference? 'arg0' is what Eclipse uses for arguments by default.
Keep lines less than 80 characters.
Bar bar = foo.veryLongMethodWithManyArguments(argument1, argument2, argument3, argument4, argument5); // don't do this
... do this instead ...
Bar bar = foo.veryLongMethodWithManyArguments(argument1, argument2, argument3,argument4, argument5);
... or this, whichever looks better ...
Bar bar = foo.veryLongMethodWithManyArguments( argument1, argument2, argument3,argument4, argument5);
This happens more than people would imagine.
Bar bar = foo.getBar(); <--- imagine there's an extra space(s) after the semicolon instead of a line break.
Make sure there's a line-break after the end of your code, and also avoid lines that have nothing but whitespace.
Every class returned by RegionServers must implement Writable
. If you
are creating a new class that needs to implement this interface, don't forget the default constructor.
Don't just leave the @param arguments the way your IDE generated them. Don't do this...
/** * * @param bar <---- don't do this!!!! * @return <---- or this!!!! */ public Foo getFoo(Bar bar);
... either add something descriptive to the @param and @return lines, or just remove them. But the preference is to add something descriptive and useful.
If you submit a patch for one thing, don't do auto-reformatting or unrelated reformatting of code on a completely different area of code.
Likewise, don't add unrelated cleanup or refactorings outside the scope of your Jira.
Larger patches should go through ReviewBoard.
For more information on how to use ReviewBoard, see the ReviewBoard documentation.
Committers do this. See How To Commit in the HBase wiki.
Commiters will also resolve the Jira, typically after the patch passes a build.