Rob, I'll trust your assessment of the technical deficiencies of the Hadoop codebase as I have no experience to say one way or the other. But I'm confused why this is relevant to wether they have a decent process & docs on how to use git?
For reference I think Erick is referring to this: https://wiki.apache.org/hadoop/HowToCommit and perhaps just the "Commit individual patches" section. FWIW I like the documentation there. Relatively succinct and represents almost exactly how I plan to work with Lucene/Solr going forward, albeit through IntelliJ and not at the command-line. My only critique of it is that I sense the git branch.autosetuprebase option (what Yonik is using) might be obsoleted by the pull.rebase option; I like the latter (newer option) better; and it makes no sense to use both. This is a nitpick though; the result is rebasing on pull. ~ David On Tue, Jan 26, 2016 at 9:06 AM Robert Muir <[email protected]> wrote: > 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] > > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
