From: Michael Widenius Date: October 21 2009 9:22pm Subject: Re: Style proposal [Re: Coding style changes of 2009-06-26 now in the guidelines] List-Archive: http://lists.mysql.com/internals/37439 Message-Id: <19167.31649.358219.242798@narttu.askmonty.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi! >>>>> "MARK" =3D=3D MARK CALLAGHAN writes: MARK> On Wed, Oct 21, 2009 at 2:41 AM, Michael Widenius wrote: >>=20 >> Hi! >>=20 >>>>>>> "Ingo" =3D=3D Ingo Str=FCwing writes: >>=20 MARK> [cut] >>>> I would also suggest that you never accept a code style >>>> convention that is not accepted by those that are affected by it >>>> (I those that produced code to MySQL or it's variants). >>=20 Ingo> Agree. That's the reason why I raised a request for ideas, how th= is Ingo> could be done transparently. I would like to have a voting system= that Ingo> accepts a vote from everybody, who works with MySQL code directly= , and Ingo> refuse votes from other people. >>=20 >> Sounds much better than the current procedure. =A0Note that to get t= his >> right, the vote should also be weighed with how much cod on has >> produced in the code base! >>=20 MARK> Has produced? MARK> Or will produce? You can't know how much code a person WILL produce. The only thing you can be sure of is the past and the contribution the person has already made. >> After all, we don't want to have people that commit a lot of code to= >> not agree with the coding style that is imposed on them and makes th= e >> code harder (for them) to read and write. MARK> For this reason votes should be weighted by: MARK> * how much code each person will write MARK> * how much code each person will read Don't know how one can judge how much code a person will read or how to prove that. MARK> What are the scale factors for: MARK> * code read/written in the past versus to be written in the futur= e? MARK> * code read versus code written? That is open for discussion MARK> Do you get votes for lines removed? If we count size of approved 'diffs' with non trivial changes, then yes= . MARK> Do votes get transferred from author to bug fixer when someone fi= xes MARK> bugs in said code? No. MARK> Do you get votes for ports or backports? I know people who worked= very MARK> hard to backport batch key access and connection pool. They deser= ve MARK> some votes for that effort. But when a port is as simple as runni= ng MARK> patch, fewer votes should be assigned. Yes, backporters are definitely working on the code, but it's not as much worth as writing new code. MARK> Do you get votes for whitespace? Heikki uses much more whitespace= in MARK> InnoDB. Perhaps he saw this coming and tried to inflate his vote MARK> count. Heikki is very clever. :) MARK> If votes also get assigned for code read, then we should strive t= o MARK> make our code as unreadable as possible to avoid diluting our vot= es MARK> for writing it. Good idea. If we make the code so hard to read, everyone has to read the same lines many times, then it causes more reads of others, which is a good thing, isn't it ;) MARK> Do you get votes for comments? Given the lack of comments in head= er MARK> files I think I know the answer to that. But I think that we shou= ld MARK> give out votes for lines of comments. I would use comments to sca= re MARK> away readers and avoid diluting my votes. Comments that contains useful, non trivial information is of course valuable. MARK> I think there should extra votes if you read code and then write = a MARK> unit test for it. All code that is added to the source should of course be tested. MARK> Does work done on branches other than the official MySQL branch c= ount? As long as the code is available under some open source license, yes, of course. We are a big happy family, aren't we? MARK> Maybe we could extend the 'karma' feature from Launchpad for this= and MARK> only count votes for work done on branches there. But I did a lot= of MARK> work on non-Launchpad branches so that makes me unhappy. If the code is released somewhere, don't see a problem with it. Regards, Monty