Ok - consensus seems to be +1 with some preference for waiting until
feature freeze or at least not overlapping with another sweeping set of
changes (which makes a ton of sense).
I'll plan to do the mass patches in a few weeks then - and in the
meantime I'll see if I can make our "mvn checkstyle:checkstyle" (and
other rules) give the same set of warnings that Jenkins does.
If I'm going to bother with this housekeeping exercise, I hope we can
keep this up (otherwise I would be happy to simply crank our thresholds
up/checks down now and call it done). I'm not sure we'd have a
volunteer to do this chore for every release...
-tom
On 03/10/2012 11:45 AM, Jeff Eastman wrote:
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
