It seems to me that the following would work:
1) All new code (contrib too) has to be formatted according to
published standards. This can be done either by the person doing the
submission, by a committer, or .... (It doesn't matter to me)
2) All existing code for which there is no patch can be changed today.
People who are working on future patches can merge the changes into
their code, possibly with some difficulty.
3) Code for which there are patches is problematic. But I would think
that if one is applying the last patch to a file, one could then
follow that with a format change.
-- DM
On Nov 10, 2008, at 7:29 AM, Grant Ingersoll wrote:
We _could_ do a wholesale change as part of 3.0, and then just make
sure that committers going forward format properly. I've seen other
projects do that.
Also, I'm not sure, but I think Hadoop's automated patch checker can
check to see if a patch is properly formatted or not. We need to
add that for our stuff anyway, so maybe it would help.
On Nov 9, 2008, at 2:59 PM, Michael McCandless wrote:
I too am bugged by inconsistent formatting and must hold back the
temptation to fix it.
And I agree a patch for a real change should not mix-in formatting
changes.
I do worry that wholesale formatting changes will obsolete pending
patches (though really we should try to keep "pending patches" at a
minimum -- hmm I see we have 73 open issues with patch available),
and make someone with alot of pending changes pull all their hair
out after doing "svn up". I'm not sure if that cost makes it worth
it net/net. Plus, unless we get help enforcing the styles over
time (eg the ideas in the Solr thread), things will likely diverge
with time again anyway.
Mike
Mark Miller wrote:
I'd like to clean up a lot of inconsistent code formatting I've
seen. Being consistent across the project would be cool, and its
easy to do with the intelij/eclipse formatting settings out there.
Looks like not so easy to get done though, as you can see from
this solr discussion: http://www.nabble.com/Code-style-td10668515.html
Some good points are made in the thread, the biggest in my mind
being that a ton of patches in JIRA become a major pain to apply/
fix.
What about a slower approach maybe? I'd be happy to do a handful
of classes a month or something. Or are there better ideas? Or are
we just stuck on this (not that its a big issue to be stuck on)?
The idea of fixing as patches come in is appealing, but not if
most people doing patches are not in on the game. And it becomes
noise in the patch - I tried to hold myself off from fixing
anything in the last patch I was working on because it just makes
it harder for someone else to look at the patch and just the
functional changes made.
It would be cool to have more consistent code though -
especially, there are some big indenting issue here and there that
really bug me.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
