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 <gsing...@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 > >
