* MARK CALLAGHAN <mdcallag@stripped> [09/03/05 19:05]:
> > All code contributed to the server must adhere to a coding
> > style. Since many parts of the server historically originate from
> > different development environments, it seems unnecessary to demand
> > that all technical teams follow the same style. Besides, the
> > existing code base doesn't satisfy this requirement.
> Excluding storage engines, I hoped that MySQL would go from no enforcement
> of coding style to enforcement for their chosen style.
Not that Monty left this can only happen after a broad acceptance
among the technical leads.
I agree with your view, but suggesting a process is a step towards
gaining support. I learned it hard way that it's impossible to
enforce a dead document - one that has not been reviewed for
I will be utmost happy if runtime, optimizer, replication, backup
and engines (i.e. all teams excluding the storage engines) agree
to have a single style.
Once acceptance is gained, we can proceed with enforcement.
> The URL you cite
> describes a style. Why can't all code other than storage engines accept
Generally, yes. I also noticed that when we talk about the style,
we pay more attention to it.
> If there is a coding style per area then those of us who work on code
> in multiple areas need multiple vim/emacs config files. Code styles are
> bound to generate a lot of process and criticism. With one style rather than
> many, much less energy will be used for all of that.
I agree. How would you, however, enforce a single style in a
distributed organization without a single leader, like ours?
The only solution I see is developing a procedure, that's what I
am trying to do.
> And to make this more fun, how are files in the sql directory classified?
> And who are the captains? How many different guides must I remember if I
> were to review a patch?
In the proposal, I suggest that a single module always follows a
single style. sql/ is mainly runtime and the optimizer. I
certainly hope that we will be able to follow a single style.
> No role has been described for the external developer community. Can we
> select our own style?
The suggestion is that the style is set for a technical area. To
account for opinions of external contributors we need to develop a
notion of core contributors -- a sort of meritocracy, when an
opinion counts based on the contribution. In any case, I am not
suggesting to exclude non-staff contributors from the decision making.