I guess my point is that since no one runs it (except perhaps you), it's not really helping anything.
And the "broken build" is really more minor than a true broken build if tests at least still pass. Personally, I'm pretty okay with a nocommit failing the build for 30 minutes if the tests still pass. Most of these issues are basic enough that anyone can jump in and fix it if it's causing them issues as well. Just remove the tabs, fix the javadoc, etc. - Mark On Dec 4, 2012, at 12:56 PM, Robert Muir <rcm...@gmail.com> wrote: > > > On Tue, Dec 4, 2012 at 3:33 PM, Mark Miller <markrmil...@gmail.com> wrote: > We are not talking about weakening them on Jenkins though. It won't wait till > release time, it will be caught 10 min later by Jenkins. > > > Right but that then doesnt really improve the situation (its less than 10 > minutes to check locally), > because if someone does "commit-and-run" we are still left with a broke build. > > I'm not concerned about this stuff tripping at all if people are looking out > and fixing stuff. > > I do have some concerns about not running the javadocs checks, because part > of the point is "check everything we can automatically" since it makes > someone go and look at the file and perhaps then they also see some text is > out of date too (not just syntax). I'm not trying to say the system is > perfect or even works, only time will tell. But I do feel like it helps keep > the documentation from falling out of date, especially when the stuff is > fresh in the committers mind. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
