I think I'm counted twice: +1 from "Bernt M. Johnsen" and -0 from "Bernt Johnson". Not that it matters ver much, but I actually voted -0.
> 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 > -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway
signature.asc
Description: OpenPGP digital signature
