And +1 on turning off all whitespace checks. Unless we all use exactly
the same formatter this will always be an issue. Personally, I think
"close enough" is fine for Mahout.
On 3/10/12 9:36 AM, Jeff Eastman wrote:
+0.5 on doing it now, unless it is going to be *right now*. I have a
pile of changes to get into 0.7 that will all need to be done in
parallel if we don't want to break clustering. This will entail a
number of big patch files and any wholesale reformatting once this
begins will be a PITA.
+1 on right after code freeze, since forward progress won't be
impacted in the interim.
On 3/10/12 4:12 AM, Grant Ingersoll wrote:
+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
