db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: [VOTE] Approve coding conventions for the Derby project
Date Wed, 16 Aug 2006 20:40:16 GMT
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


Mime
View raw message