* Michael Widenius <monty@stripped> [09/06/30 11:31]:
> Konstantin> On Friday, 2009-06-26, the group that governs MySQL server coding
> Konstantin> style met for the first time, and considered two proposals:
>
> Konstantin> 1) Removing the switch alignment exception.
> Konstantin> http://lists.mysql.com/internals/36385
>
> Konstantin> 2) Specifying the function parameter names in declarations.
> Konstantin> http://lists.mysql.com/internals/36404
>
> Konstantin> Both proposals were accepted by the majority of votes (5 out of 6
> Konstantin> on both).
>
> Who voted which way ?
The list of representatives is documented at:
http://forge.mysql.com/wiki/Coding_Style
Quoting:
* Sergey Petrunia - Optimizer
* Konstantin Osipov - Runtime
* Mats Kindahl - Replication
* Chuck Bell - Backup
* Guilhem Bichot - Maria
* Sergey Vojtovich - Engines
Proposal 1: everybody voted favourably except Chuck Bell
Proposal 2: everybody voted favourably except Konstantin Osipov
> Why is the developer community outside of Sun not properly represented ?
This group contains one representative from each technical
team/area. WRT community involvement, teams select their
representatives, they are not assigned by Sun managers.
I fully expect there to be agreement within technical teams
which member of the team is part of the committee.
I disagree that community outside Sun is not properly represented.
Perhaps, those who're the loudest are not represented :->
SergeyP, for example, is now at Monty Program AB, and is part of
the committee.
> Why doesn't everyone that is affected by this change have the right to
> vote ?
I'm afraid I don't understand how this can ever be possible.
> Konstantin> You can find more details here:
>
> Konstantin> http://forge.mysql.com/wiki/Coding_Style
>
> Konstantin> This change will be effective once the Forge document is updated,
> Konstantin> I will write a separate update on that.
>
> Konstantin> However, in order to do that, I need help:
>
> Konstantin> 1) Could someone using emacs send me the new formatting options
> Konstantin> for emacs to take into account the new switch () style?
>
> Konstantin> I will try to handle the task for vim but won't mind a helping
> Konstantin> hand here either.
>
> Sorry no, as I am not going to accept this ruling as I don't think
> that the committee is representative for those that are going to drive
> MySQL development forward in the future.
> In the past when we had votes for coding style changes in MySQL,
> everyones vote counted!
> Sorry, but I don't think this is the way to drive an open source
> project if you really want people outside of our group to participate
> in developing it.
> By the way, have you checked that the windows C++ editor supports the
> suggested style at all ?
Yes.
> Konstantin> 2) The second proposal conflicts with some ctags usage patterns.
> Konstantin> I will need to investigate whether it indeed confuses ctags, and
> Konstantin> whether this can be avoided.
>
> I am using etags and for that there has never been a big problem with
> this.
>
> By the way, when it comes to doing changes that this that affects
> style, the best thing would be to do it the following way:
>
> - Agree on a change.
> - Go trough all active MySQL releases (the ones you will sooner or
> later merge from)
> - Fix code completely in one release (with some macro/program)
> - Merge to next version
> - Fix things in that version.
> - Work with the community with all active forks to help them do the
> same.
>
> In some part it's good that there is a committee for coding style
> changes as I think it's their job to ensure that the above is done,
> either by getting someone to do it or by doing it themselves.
>
> If you don't do this, you will never get a new code style used as
> people will always copy code from one place to another and there will
> be new code with the old style.
I can not answer this, and some other questions of this email, sorry.
It's an endless debate of "who makes the decision", which I at
this point refuse to participate in. I'm happy enough at this
point the problem is moving forward, albeit it's perhaps not an
ideal solution.
--
