I am entirely serious, but we all know the code quality problems with hadoop. Many are the same ones Uwe has already fought here and you can already find issues/discussions on them:
* any hadoop maven artifact is "jar hell in a box" * hadoop classes do crazy shit, like execute operating system processes when classes load. * at the same time, hadoop is not really portable (e.g. hdfs just fails on windows without native libraries). furthermore, I have seen a push for a lot of apache projects to follow a "typical" hadoop-like development style. You can recognize certain features of it like trying to enforce code reviews, review-then-commit, etc. It recently caused a big thread on the incubator lists. personally, I agree with some of the comments there, that making it too hard to get commits in discourages code cleanups and things like that (which appear to be desperately needed if you actually look at the code) I also think their approach to backwards compatibility and JVM version support plays a big role. If they stopped pretending they could run on ancient java versions and just adopted java 7, they would actually be *more* portable (e.g. work on windows) and not less. Also use of NIO.2 instead of trying to execute processes like 'ln -s' for handling files is way cleaner. On Tue, Jan 26, 2016 at 8:03 AM, Erik Hatcher <[email protected]> wrote: > Robert - not sure if you're serious or not but I'd love to see an example of > the (lack of?) code quality especially in how the dev practices there > contributed to it. Pointers? > > Erik > >> On Jan 26, 2016, at 06:16, Robert Muir <[email protected]> wrote: >> >> I don't think we should follow the hadoop dev practices, just look at >> the quality of the code they produce... >> >>> On Mon, Jan 25, 2016 at 7:49 PM, Erick Erickson <[email protected]> >>> wrote: >>> OK, I'm _really tempted_ to just steal the Hadoop guide verbatim as a >>> start and we can refine as necessary. >>> >>> I'll put big banners about "PRELIMINARY" in it, and add bits about >>> this being recommended not required. >>> >>> Thoughts? >>> >>>> On Mon, Jan 25, 2016 at 4:36 PM, Uwe Schindler <[email protected]> wrote: >>>> Hi, >>>> >>>>> Another chore we do is on adding new files is >>>>> svn propset svn:eol-style native <file-name> >>>>> >>>>> do we have an equivalent for that in git? >>>> >>>> Per-file properties like eol-style or MIME-type don't exist. Git has some >>>> set of internal file extensions it treats as text files and does the >>>> newlines automagically. If we want to configure that, we can commit a >>>> ".gitconfig" file in root directory of repository: >>>> https://help.github.com/articles/dealing-with-line-endings/ >>>> >>>> I would like to add such a .gitconfig file in any case to do some sane >>>> defaults. >>>> >>>> The ANT checker in "precommit" now also checks your GIT working copy and >>>> fails like before, although it no longer looks at mime types or eol-style. >>>> >>>> Uwe >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
