List:Internals« Previous MessageNext Message »
From:Konstantin Osipov Date:June 30 2009 11:59am
Subject:Re: [style] [annc] Coding style update
View as plain text  
* 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>
> Konstantin> 2) Specifying the function parameter names in declarations.
> Konstantin>
> 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:

* 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>
> 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
> 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.

[style] [annc] Coding style updateKonstantin Osipov29 Jun
  • re: [style] [annc] Coding style updateMichael Widenius30 Jun
    • Re: [style] [annc] Coding style updateKonstantin Osipov30 Jun
      • Re: [style] [annc] Coding style updateMichael Widenius30 Jun
        • Re: [style] [annc] Coding style updateAlex Esterkin1 Jul
    • Re: [style] [annc] Coding style updateIngo Strüwing1 Jul
  • Re: [style] [annc] Coding style updateTor Didriksen2 Jul
    • Re: [style] [annc] Coding style updateGuilhem Bichot2 Jul
      • Re: [style] [annc] Coding style updateTor Didriksen2 Jul
        • Re: [style] [annc] Coding style updateTor Didriksen2 Jul
          • Re: [style] [annc] Coding style updateGuilhem Bichot2 Jul
      • Re: [style] [annc] Coding style updateIngo Strüwing2 Jul
  • Re: [style] [annc] Coding style updateTor Didriksen3 Jul