>> Please understand that by taking this attitude you waste everyone >> else's time who does want to pass "ant precommit" before committing, >> and everyone else's time to scan all these broken builds emails.
+1 personally ... i'm past the point of willing to overlook people who obviously break the build ... ranodmized / timing sensitive test failures are one thing -- but failure to compile, failure to pass precommit ... these are obvious mistakes that can be easily caught in advance, and create blocks preventing for other developers. that's un-fucking-acceptable. If i'm working on something, and discover that a recent commit has broken precommit, I revert. no discussion, no hesitation : It's temporary - package private stuff will migrate to public. It's : not in it's final form and not meant to be a public API, but some : things have to be public for internal cross-package use. Then commit to a branch, or keep it in a patch, or keep it in a github fork. This project has evolved to trying to have the best safe guards we can against broken code making it into the repo -- if people ignore those safe guards, they have no right to complain when the rest of us call them out on their bull shit and/or revert their commits. : My point is that javadoc shouldn't fail stuff that java is happy with. java is happy with "nocommit" in source files, and "@author" tags -- that doesn't mean we as a project are. If the most efficient way to find these types of problems is by validating the javadocs -- as opposed to spending a lot of time writting some sort of justom source code analysis -- then so be it. -Hoss http://www.lucidworks.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
