db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernt M. Johnsen" <Bernt.John...@Sun.COM>
Subject Re: [VOTE] Approve coding conventions for the Derby project
Date Wed, 16 Aug 2006 21:26:24 GMT
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

Mime
View raw message