mahout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Owen <sro...@gmail.com>
Subject Re: Mass Code Cleanup
Date Sun, 14 Feb 2010 21:53:38 GMT
I don't see evidence that new code comes in with nearly-correct style,
nor efforts to correct style in existing code as part of patches -- am
I missing this? So I'm missing the force that will make this happen,
short of visible efforts like this, which are being resisted. AFAICT
it's not going to happen then, and nobody thinks that's good.

I take the point about long-lived patches, but right now we have none
save perhaps Jake's that stand any chance of being committed. But
piecewise fixes also have the problem of breaking patches. That's not
different. As do any of the API changes bound to happen between 0.2
and 1.0. In such a project, a patch that lives more than a few weeks
is bound to accumulate conflicts.

Is it so painful to take a small hit once to get 90% there, then sweat
the details in due course? Nobody's calling for a hackathon or any
active work at all beyond merge pains (which, theoretically, should
not have been there in the first place.)

Code style is even more important in open source than inside a
corporation. Thousands of people need to grok the code as easily as
possible, and industry-standard style goes a long way towards that.
That said, we all know it'd be harmful to reject contributions and
experiments for small reasons of style. But, I am having trouble
understanding objections to others taking that work.

... has nobody then noticed the quite large code analysis changes I've
been committing? This is hundreds of lines a week. And so far no
trouble that I can tell?

On Sun, Feb 14, 2010 at 9:36 PM, Grant Ingersoll <gsingers@apache.org> wrote:
> 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
>
>

Mime
View raw message