First I want to say that I hope the community will continue to vote on
this issue while discussion is underway about whether or not Rick will
veto. I am sure the next person to take a shot at this will appreciate
knowing where everyone stands even if it doesn't pass this round. See
http://db.apache.org/decisions.html for responsibilities and
definitions of voting. I think this is a consensus vote.
Rick Hillegas wrote:
Just want to make sure we have realistic expectations for this vote:
Since we are not bulk-reformatting the code, even after this vote
Derby won't conform to the db project guidelines.
Yes, my hope is that incrementally we can reach a point where we conform
to the db project guidelines. The question is how much closer we can
get to that now. I tend to think, the lack of such a convention for
Derby was just a serious oversight in allowing Derby to graduate
incubation.
The guidelines don't specify how extensive the hard-and-fast rules
have to be. To date, here are the only ones I think we have discussed
extensively:
1) No tabs.
2) Indentation stops set at 4 spaces.
3) Line length not to exceed 80 characters.
To this, with the community's approval, I would add
0) Write clearly.
A good enough coding standard would be these 4 hard-and-fast rules
plus a pointer to a non-binding style primer. Let's keep it simple and
focus on the issues which actually bothered us.
If incremental consensus has to start there, I suppose it could, but I
don't think it would qualify as a "well-defined convention" and I do
think we would need to adopt a well-defined convention in the future in
our work to comply with the db project guidelines. I am curious for
matters of db project guidelines, who could answer what level of
specificity is required.
I disagree that this would solve all the issues. I think still there
would be issues with IDE's reformatting code, various religious
discussions around particular changes and the core problem would
remain (even after removal of the note) that a new developer can't rely
upon setting their IDE to some documented convention and be sure they
won't get into trouble with it. I think we need to be setup so it is
easy to join the project and make a fix. Those making changes for
style need to make sure that their style decisions are not going to
interfere with anyone using the documented convention and that is it.
That is not possible with the 4 rules and primer pointer wording.
It is different from closed source where we might expect some small
group of core developers to learn how to work around and integrate each
other's styles. ( I actually have a .emacs file that seems to have the
beginning of this conversation years ago, I am not even sure who wrote
it or who "I" is in this context, but it has various commented out
sections and says .." Nat's favorite is ... Ame's said .... I like it
like ... We still haven't decided about switch statements" etc.) This
kind of thing does not scale well to an open source project with
potentially hundreds of contributors all showing up to build great
extensions and and make fixes just want to know some format to use that
won't get them into trouble. They don't really care what color the shed
is, just give them something that works and if we are not militant about
it and allow variations that make sense and don't interfere, then we are
covered.
I think we should publish the convention as proposed and our ultimate
goal should be that anyone formatting their code in this way is not
going have to ever redo their patch based on formatting issues.
Thanks
Kathey
