List:Internals« Previous MessageNext Message »
From:Jay Pipes Date:October 23 2009 3:04pm
Subject:Re: Style proposal [Re: Coding style changes of 2009-06-26 now in the
guidelines]
View as plain text  
Konstantin Osipov wrote:
> * MARK CALLAGHAN <mdcallag@stripped> [09/10/21 16:09]:
> 
> The current system, as documented in the internals manual:
> 
>  - each technical team has 1 vote. A technical team is responsible
>    for all patches, bugs, features in a certain area of the server.
>  - to vote, each technical team elects a representative. It's up
>    to them how they do it -- they can decide that someone
>    non-employed by MySQL/Sun is good for them.
> 
> This is it. 
> What technical teams are out there? Optimizer, Replication,
> RuntimeEnv, Backup, Engines, etc. Who's on the team? This is our
> internal org. chart, but some teams include external contributors. 
> Right now it is based on how the server organization in MySQL
> functions. Yes, it's not totally transparent to the community, and
> yes, below you write some nifty ideas that could improve fairness.
> But to me what we have is good enough. Besides, most of MySQL
> development is still done internally. I know it's bad, and all,
> and Drizzle is managing better. Speaking of which: what's the
> procedure there? Perhaps what you say should be first piloted in
> this project, and then MySQL learns from them?

Here is an example of Drizzle's "procedure" :)

Jay gets confused about code paths in MySQL/Drizzle and posts a blog 
entry bitching about something that he has gotten entirely wrong.

Sergei corrects Jay once, twice, three times, with Jay arguing that 
Sergei is incorrect.

Jay finally realizes Sergei is correct and apologizes.

Jay then realizes if only certain things were more clear in the code, 
his life wouldn't be so hard.

Jay posts an overly-long description of why functions should have better 
functional documentation in the header files to drizzle-discuss@ mailing 
list.

A discussion ensues with Drizzle community folks (including MySQL 
developers, BTW) about whether comments should go in header files or in 
the actual source code file.

Votes are cast as +1 or -1 or +10 or -500, some with some detailed 
explanation arguing the case for or against.

If a consensus materializes out of these votes, someone (usually MontyT, 
myself, or Padraig) posts back to the mailing list saying essentially, 
"OK, it looks like the consensus is to do XXX"

That person adds it to the online style guide:

http://drizzle.org/wiki/Coding_Standards

The style and coding standards are enforced to the best of the 
community's ability during the public, online code reviews when branches 
are proposed for merging.

Cheers!

Jay

p.s. I'm hoping Sergei gets a kick out of my above explanation. :)

>> For this reason votes should be weighted by:
>> * how much code each person will write
>> * how much code each person will read
>>
>> What are the scale factors for:
>> * code read/written in the past versus to be written in the future?
>> * code read versus code written?
>>
>> Do you get votes for lines removed?
>> Do votes get transferred from author to bug fixer when someone fixes
>> bugs in said code?
>>
>> Do you get votes for ports or backports? I know people who worked very
>> hard to backport batch key access and connection pool. They deserve
>> some votes for that effort. But when a port is as simple as running
>> patch, fewer votes should be assigned.
>>
>> Do you get votes for whitespace? Heikki uses much more whitespace in
>> InnoDB. Perhaps he saw this coming and tried to inflate his vote
>> count. Heikki is very clever.
>>
>> If votes also get assigned for code read, then we should strive to
>> make our code as unreadable as possible to avoid diluting our votes
>> for writing it.
>>
>> Do you get votes for comments? Given the lack of comments in header
>> files I think I know the answer to that. But I think that we should
>> give out votes for lines of comments. I would use comments to scare
>> away readers and avoid diluting my votes.
>>
>> I think there should extra votes if you read code and then write a
>> unit test for it.
>>
>> Does work done on branches other than the official MySQL branch count?
>> Maybe we could extend the 'karma' feature from Launchpad for this and
>> only count votes for work done on branches there. But I did a lot of
>> work on non-Launchpad branches so that makes me unhappy.
> 

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