On Feb 14, 2010, at 4:25 PM, Jake Mannix wrote: > On Sun, Feb 14, 2010 at 12:16 PM, Benson Margulies > <bimargul...@gmail.com>wrote: > >> It seems to me that Robin's campaign is predicated on a prior decision >> as to what checkstyle rules we want to enforce. We can't have it both >> ways. if we want to enforce cs compliance for a ruleset, we've got to >> make the code comply, and one big tornado has something to recommend >> it. If, in fact, we are still in flux in terms of choosing the rules >> we want to enforce, then we have a different problem. >> > > I don't think that deciding to go with one checkstyle choice also means > tha twe "have to" make the code comply. It means that we should be > attempting to make new checkins comply, certainly.
Agreed. We should apply it going forward on those files that have been touched. We have to be vigilant about what's coming in (Hadoop even goes so far as to -1 a patch if it doesn't meet the Hadoop style, and all of this is done automatically) but we shouldn't retrofit. It will cause us committers way more work in the long run. I've been through this before w/ Lucene and sweeping code reformatting is a big pain in a multi-committer environment. There will often be patches that we won't get to for 1, 2 or even 3 releases, especially as we grow. The easier it is to bring them up to date the better. -Grant
