List:Internals« Previous MessageNext Message »
From:MARK CALLAGHAN Date:October 23 2009 1:47pm
Subject:Re: Style proposal [Re: Coding style changes of 2009-06-26 now in the
guidelines]
View as plain text  
On Thu, Oct 22, 2009 at 11:36 AM, Michael Widenius <monty@stripped> wrote:
>
> Hi!
>
>>>>>> "Ingo" == Ingo Strüwing <Ingo.Struewing@stripped>
> writes:
>
> Ingo> Hi Monty,
> Ingo> Michael Widenius, 21.10.2009 11:41:
>
> Ingo> ...
>>> Note that to get this
>>> right, the vote should also be weighed with how much cod on has
>>> produced in the code base!
>
> Ingo> I understand your position. But you are leaving democratic grounds. You
> Ingo> don't have my support with this.
>
> In democracy, there is many cases where weights are different.
> Democracy doesn't guarantee equality, only that everyone has a chance
> to have their voice heard.

MySQL seems to have chosen a representative democracy rather than a
direct democracy and it appears unlikely that you will be chosen as a
representative unless you work there. I am not complaining --
outsiders still have a role in the process. They also have chosen good
representatives.

But MySQL is also a company so we should expect to lose some rights
when we are/were paid to work there, when we sold copyright to them
and when we don't work there.

>
> However, in typical open source projects, there is always a 'weight'.
> People are given different number of votes or weights; Usually one or
> two core engineer can kill any ide that 10 normal people has
> suggested. (So for example how PostgreSQL or Drizzle development
> works).

There are two issues here:
1) whether votes should be weighted
2) how to weight votes

The issue of how to weight votes is complex. I think that the weight
should be based on what you will do rather than what you have done.
Lets call this stock market weighting as one theory is that the price
of a stock is based on the expected future performance of it. If only
we could predict future productivity, then this is perfect.

You want the weight to be based on what you have done in the past.
Lets calls this corporate weighting as some people (me) think that
power in big corporations is often assigned that way. This frequently
results in big corporations becoming defunct corporations as they
waste their energy fighting last year's or last decade's battles.

>
> Then you also have 'ownership' of the code:
>
> - People 'own' the code they have written.
> - You don't change other peoples code, without asking them permission.
> - Only when a person gives up his code, then someone else can take
>  over it.

Ownership is diluted when other people begin improving, maintaining
and debugging that code.

Ownership is also determined by the culture at Sun/MySQL engineering
as this is a company run/funded project. Drizzle is a community run
project. We have a choice.

>
> This is common in perl, php, PostgreSQL and most other communities
> that I know of.  It was the case also in MySQL before, but not anymore
> :(

I don't think they are run as you describe. But I haven't participated
in them and I don't think you have. I have reviewed PostgreSQL code.
It has a common coding style that appears to be enforced and comments
in header files. That makes me happy.

>
> The effect of the above is that people that has produced more code,
> has more to say. Nothing wrong with that.
>
> Another way to see this is also that you should not force the people
> that produces the most code to code in a style they don't like.  That
> will just make these people less productive and over time do something
> else than produce code for that project.

Ignoring the issue of has produced versus will produce, you assume
that 'lines of code' is all that counts. That is an awful metric when
used in isolation. Someone who writes a lot is less productive when:
* other people spend years fixing bugs in that code
* production users spend years dealing with problems from that code
* that code is difficult to reuse (no comments, no design notes, lousy
structure)
* that code is difficult for others to maintain
* that code required too many lines of code

-- 
Mark Callaghan
mdcallag@stripped
Thread
Coding style changes of 2009-06-26 now in the guidelinesIngo Strüwing17 Oct
  • Re: Coding style changes of 2009-06-26 now in the guidelinesMARK CALLAGHAN17 Oct
    • Re: Coding style changes of 2009-06-26 now in the guidelinesMichael Widenius18 Oct
      • Re: Coding style changes of 2009-06-26 now in the guidelinesMARK CALLAGHAN18 Oct
        • Re: Coding style changes of 2009-06-26 now in the guidelinesMichael Widenius18 Oct
          • Re: Coding style changes of 2009-06-26 now in the guidelinesJay Pipes18 Oct
          • Re: Coding style changes of 2009-06-26 now in the guidelinesMARK CALLAGHAN18 Oct
            • Re: Coding style changes of 2009-06-26 now in the guidelinesMichael Widenius19 Oct
    • Re: Coding style changes of 2009-06-26 now in the guidelinesIngo Strüwing19 Oct
      • Re: Coding style changes of 2009-06-26 now in the guidelinesMats Kindahl19 Oct
        • RE: Coding style changes of 2009-06-26 now in the guidelinesVladislav Vaintroub19 Oct
          • Re: Coding style changes of 2009-06-26 now in the guidelinesMats Kindahl19 Oct
            • RE: Coding style changes of 2009-06-26 now in the guidelinesVladislav Vaintroub19 Oct
            • Re: Coding style changes of 2009-06-26 now in the guidelinesRoy Lyseng19 Oct
          • RE: Coding style changes of 2009-06-26 now in the guidelinesMichael Widenius21 Oct
      • Re: Coding style changes of 2009-06-26 now in the guidelinesMARK CALLAGHAN19 Oct
        • Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Ingo Strüwing19 Oct
          • re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Michael Widenius21 Oct
            • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Ingo Strüwing21 Oct
              • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Michael Widenius21 Oct
                • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in the guidelines]MARK CALLAGHAN21 Oct
                  • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in the guidelines]Michael Widenius21 Oct
                  • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Konstantin Osipov23 Oct
                    • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Jay Pipes23 Oct
                • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Ingo Strüwing22 Oct
                  • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Michael Widenius22 Oct
                    • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Ingo Strüwing22 Oct
                      • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Michael Widenius23 Oct
                    • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in the guidelines]MARK CALLAGHAN23 Oct
                      • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in the guidelines]Michael Widenius24 Oct
        • Re: Coding style changes of 2009-06-26 now in the guidelinesMichael Widenius21 Oct
          • Re: Coding style changes of 2009-06-26 now in the guidelinesMARK CALLAGHAN21 Oct
            • Re: Coding style changes of 2009-06-26 now in the guidelinesMichael Widenius21 Oct