+1 on doing it now. Another approach we might also consider is simply deferring all reformatting to release time. In other words, all committers should try to keep things in line when committing, but then at release time we just do a bulk reformat. I think it's reasonable to ask people to upgrade their patches after a release anyway. Then, we could turn off the Jenkins formatting checks, as we know the code will be pretty for every release and hopefully it won't drift too much in the interim.
My bikeshedding proposal, -Grant On Mar 9, 2012, at 12:44 AM, Jake Mannix wrote: > On Thu, Mar 8, 2012 at 9:10 PM, tom pierce <t...@apache.org> wrote: > >> I could support this plan, but it might be hard to say something like "ok, >> this week we're lowering the threshold another 50 warnings - no more >> commits until we're passing again!". It's the sort of thing that is easy >> to keep deferring until you eventually forget you meant to do it. >> >> I guess I'm a "just rip the band-aid off" kind of guy; suffer quickly and >> move on. Speaking of that, any feedback on MAHOUT-987? > > > Historically I've been a strong opponent of big batch "fix a ton of > whitespace" commits, because it makes for ugly commit/blame history, > potentially invalidates patches, and similarly makes for merging other > branches (i.e. on GitHub) painful. > > I'm not sure if I have enough strength left in me to hold to that argument, > as my "broken windows theory" sense is deeply offended by the way I've > already gone way past "might" bitbucket the "unstable Jenkins build" > emails, and into "am totally ignoring it because it's noise"-land. > > So I guess I'm surprisingly enough a +1 on this ticket, at present. We > should hear back from more of a quorum on a commit that hits so many files > in different places. > > -jake > > >> >> >> -tom >> >> >> On 03/08/2012 11:25 AM, Jeff Eastman wrote: >> >>> +1 I'd like to see Jenkins become a reliable health indication and >>> setting the fb/pmd/cs bar too low does us no service unless we are prepared >>> to take those warnings seriously. Is it possible to raise the bar to where >>> we are "ok" again and then agree to lower it periodically to get us to >>> improve our hygiene index? >>> >>> >>> On 3/7/12 7:04 PM, Tom Pierce wrote: >>> >>>> Well we already have that in a sense - all the tests still run and we >>>> can see which fail even if findbugs/pmd/checkstyle have lots of >>>> complaints. >>>> >>>> My concern would be having 2 separate Jenkins tasks would make it even >>>> easier to ignore the non-test warnings. >>>> >>>> I'd much rather make "mvn test" fail when findbugs/pmd/checkstyle >>>> counts go up, or drop those tasks from Jenkins entirely. This would >>>> let us all test against the same rules as Jenkins in a straightforward >>>> way. >>>> >>>> I'm only bringing this up because it bugs me that I'm starting to >>>> mentally bit-bucket "build is unstable" email, which is a terrible >>>> habit. >>>> >>>> -tom >>>> >>>> On Wed, Mar 7, 2012 at 3:59 PM, Dmitriy Lyubimov<dlie...@gmail.com> >>>> wrote: >>>> >>>>> On Tue, Mar 6, 2012 at 10:04 PM, Paritosh Ranjan<pran...@xebia.com> >>>>> wrote: >>>>> >>>>>> About Jenkins: >>>>>> Will it be good to create separate maven profiles executed using >>>>>> separate >>>>>> Jenkins jobs for >>>>>> a) normal build without findbugs/checkstyle/pmd etc >>>>>> b) quality build with findbugs/checkstyle/pmd >>>>>> >>>>> Is it the intended distinction between normal and quality build? if >>>>> yes, +1, seems reasonable. >>>>> >>>> >>>> >>> >> -------------------------------------------- Grant Ingersoll http://www.lucidimagination.com
