I don't really know the YARN or MAPREDUCE code bases so I'm going to
pass on those ones...
Todd asked a pretty reasonable question that I don't see an answer to
-- where will murmur3 actually be used? We generally don't add code,
even if it's good code that we're sure to need someday, until there's
an actual user for it.
There needs to be a complete, up-to-date patch uploaded. This one
seems to have two patches that need to be applied to get a working
commit -- HADOOP-9041.patch and fsinit-unit.txt. Also the latter has a
misspelled classname, Initialization is spelled with a "t" rather than
It would be really good to develop a JUnit test that fails reliably
both under mvn and Eclipse that shows the problem to avoid regressions
in the future... even if the unit test has to do moderately unclean
things to force the failure. (But that's not a hard requirement, if
it's really impossible to do the current situation is OK.)
I don't understand this patch at all. Since it makes the constructor
vacuous, why not just delete the constructor entirely? If avoiding the
possible "could be null" makes other code simpler, go ahead and
include the simplification in this patch. (see below for more on
including stuff in a single jira.)
Generally if Jenkins posts a -1 on a patch, you should follow up with
a comment explaining why it's OK for this patch to fail the given
test. For example I had a change recently that fixed an intermittent
test failure, so I didn't need to add a test. Jenkins said "-1 no
tests included" and I commented "fixes TestFoo intermittent failures".
One of the ways the community has compensated for the heavyweight JIRA
process is to allow a single JIRA to include more change than I would
normally put into a git commit. I do my development locally in a
per-jira branch "hdfs1337" with normal small git-style commits, and
then when I'm ready to post a patch I "git diff
upstream/trunk..hdfs1337 > hdfs1337.txt" to squash all the sane git
commits into a single large diff to upload.