>>>>> "Konstantin" == Konstantin Osipov <kostja@stripped> writes:
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> 2) Specifying the function parameter names in declarations.
Konstantin> Both proposals were accepted by the majority of votes (5 out of 6
Konstantin> on both).
Who voted which way ?
Why is the developer community outside of Sun not properly represented ?
Why doesn't everyone that is affected by this change have the right to
Konstantin> You can find more details here:
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 ?
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
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
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.