Kathey Marsden wrote:
Below are the results from this vote:
[+1] Adopt the coding convention described.
David Van Couvering (Committer)
Bryan Pendleton (Committer)
Craig Russell
Kristian Waagan
Knut Anders Hatlen (Committer)
Narayan
Dag Wanvik
Andreas Korneliussen (Committer)
Kathey Marsden (Committer)
Bernt M. Johnsen (Committer)
Olav Sandstaa
-0
Rick Hilegas (Committer)
Mike Matrigali (Committer)
Bernt Johnson (Committer)
-.25
Suresh Thalmamati. (Committer)
Did the vote pass? I am not totally sure, but I think so.
Did we reach consensus? I don't think so.
I think such a vote should be pure formality and all necessary
discussion and refinement should happen before hand. Clearly there was
more discussion needed and I think the discussion in the course of this
vote was some of the most productive we have had on the topic. If I
could go back in time and add the amendment:
- Derby encourages writing of clear code and use of common sense and
does not discourage variations from the convention that lead to better
code clarity and do not interfere with the general use of the
convention by others in the project.
Some general comments from the discussion. I hope I got this right.
Please respond with corrections additions.
In general
As things stand, we could better document the tab stop 4. clear code
and no formatting/white space diffs in patches to mitigate our current
problems.
On the postive side:
- Most folks thought the amendments and note were good.
- Clarity on our long term direction for tab/spaces and convention
will help us develop an action plan to address those issues.
Positive comments on having a fairly specific convention.
- Having a fairly specific convention that contributors and
editor stetting that contributors can use safely without extended
discussion will save the project lots of time and potential confusion.
- Having braces etc all the same leads to better overall code
clarity.
On the negative side:
- The wording was too strong about the convention to use and made
it sound mandatory and might interfere with common sense and clarity of
code .
- Ultimate reformatting to the convention would cause ":merge
hell" (I don't think this is true if we reformat all the branches)
- Folks wanted to get the space/tab issue and problem of
reformatting in patches resolved more independently from any long term
convention. (I am concerned that this might lead to the need to
reformat twice if other issues arise).
- Wanted a better statement of the problems we are trying to solve
before solutions were presented.
- Did not like having to adapt to tabs or spaces of the surrounding
code. Wanted a clear setting of tabs or spaces which would be ok. (I
don't think we can do this given the current state)
- Code conventions for the sake of db project guideline compliance is
not a good motivation.
I am not exactly sure how to proceed moving forward. The incremental
consensus approach is good I think, but perhaps this step was to big
and too prescriptive for the next step of resolving inconsistencies in
the code (especially tab/spaces).
I think I will detach from this for a bit and not update anything on
the contributor checklist. If someone wants to pick it up and glean
some areas of clear consensus from it that can go on the checklist or
wants to take other action, please do. This thread is here for
historical context for all and especially for whomever wants to
continue. I might look at it again later after witnessing the next
hazing ritual if no one else has.
Kathey
