On Mon, Feb 14, 2011 at 6:04 PM, Grant Ingersoll <[email protected]> wrote: > I can tell you that I often stop reviewing a patch as soon as I notice it > doesn't have tests. In fact, I wish we could get the Hadoop Hudson > auto-test stuff hooked in so that it would -1 patches that don't have tests. > So, if it sorely needs to be committed, then it sorely needs tests written. >
+1, I really wish we had this hooked in. there are just so many things that its impossible to stay on top of, these are my 3 biggest pet peeves coming to mind 1. javadocs warnings/errors: this is a constant battle, its worth considering if the build should actually fail if you get one of these, in my opinion if we can do this we really should. its frustrating to keep the javadocs warnings down to zero, yet we shouldnt have invalid references etc in our documentation. 2. introducing new compiler warnings: another problem just being left for someone else to clean up later, another constant losing battle. 99% of the time (for non-autogenerated code) the warnings are useful... in my opinion we should not commit patches that create new warnings. 3. svn-eol style, i run a script periodically and convert all of this. It seems a lot of people don't have their svn's configured to set this automatically. Please configure your subversion according to apache standards: http://www.apache.org/dev/svn-eol-style.txt, especially if you care about being able to see line-by-line history. Otherwise my script will periodically perform massive changes to the codebase, including in some cases changing every single line of code in affected files. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
