+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
