First, i don’t think the intention of the rule is a bad thing. However, the idea was, in my opinion, executed in a remarkably poor way.

First, the initial posting: i will take the liberty of linking to Debian Community Guidelines — hopefully, some people read it and stick with at least some of the points. Note that there are no rules in the guidelines, just suggestions. However, for the most part, i find the suggestions useful (which is a good reason to stick with them, right?).

To dissect the posting a bit:

The net result is, as expected, a huge flamewar that trenches productivity and gets nothing done. The author probably assumed, that there is no way this would get away without one, so he encouraged it… I think that if the post was written a bit more carefully, there would be far fewer objections.

So let me make a try on formulating a post that addresses same problem (messed up indentation):

Hi,

It has been observed, that kdelibs has (admittedly quite bad) problem with indentation and consistency. We have come up with a few guidelines and measures to overcome this.

First, the existing guideline saying that new contributions should follow current file style is inefficient — and i think it is due to poor tool support, not due to people screwing the style on purpose. There are things that can help with this: editor modelines and directory variables.

The first measure is to add a default (fallback) style to toplevel kdelibs directory. This should be the Qt style, as attached, because it both is close to what kdelibs already uses and is natural since we use Qt a lot. The accompanying guideline would be similar as before, follow the style of the subsystem you are changing.

Subsystems that already have a consistent style should get their own dirvars or modelines, so that it is easy for contributors to follow it. We will do this for those we know about and that should also provide a template for other subsystem maintainers to pick up and use. Additional bonus points for having a HACKING file in the subsystem directory describing the style and communicating other useful information about the code.

The last measure of this kind is to provide astyle settings that match the used styles, so people who have problems following styles can, after editing, but before committing, run changed files through astyle to comply with the guideline without too much effort. This could go into the HACKING file as well. (This may need more discussion, because if astyle is not capable of doing this well, ie. adding random unneeded changes to unrelated parts of file, it will clearly become counter-productive).

Second, there are two technical difficulties with reindenting sources and subversion: that of svn blame and that of revision diffs (which are attached to commit mails). Both are being addressed by subversion developers, i believe (consult this archive thread from january of this year). Doing mass-reindent now will break svn blame temporarily (until blame -w is implemented in subversion). Not doing mass-reindent will break diffs in commit mails (make them unreadable) and gradually break svn blame until -w is implemented.

I believe that breaking svn blame temporarily, but keeping useful commit mails, is a better compromise. This means, that files that have internally inconsistent style, or are a part of larger body of code (subsystem) that follows a style different from their one, will get reindentend in one go and one commit (preferably through the scripty account, so that output of blame is still useful even while broken).

That’s about it, i hope the proposed solutions will lead to more consistent and more enjoyable hacking experience in kdelibs, without impeding our productivity.

Yours, impersonating-someone-who-matters Peter.