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] List-Archive: http://lists.mysql.com/internals/37447 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 22, 2009 at 11:36 AM, Michael Widenius wro= te: > > Hi! > >>>>>> "Ingo" =3D=3D Ingo Str=FCwing 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 > =A0over 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. =A0It 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. =A0That > 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 --=20 Mark Callaghan mdcallag@stripped