From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55504 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Onsic-0003pQ-NS for qemu-devel@nongnu.org; Tue, 24 Aug 2010 08:35:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Onsia-0001p9-C1 for qemu-devel@nongnu.org; Tue, 24 Aug 2010 08:35:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6168) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Onsia-0001ok-4o for qemu-devel@nongnu.org; Tue, 24 Aug 2010 08:35:08 -0400 From: Markus Armbruster Subject: Re: [Qemu-devel] [PATCH 0/5] CODING_STYLE amendments References: <4C6A4291.1020105@redhat.com> <4C6A8CD8.2080701@codemonkey.ws> <4C71550F.6080602@redhat.com> <4C716FB3.2090505@codemonkey.ws> Date: Tue, 24 Aug 2010 14:34:57 +0200 In-Reply-To: <4C716FB3.2090505@codemonkey.ws> (Anthony Liguori's message of "Sun, 22 Aug 2010 13:42:59 -0500") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Blue Swirl , Jes Sorensen , Miguel Di Ciurcio Filho , qemu-devel Anthony Liguori writes: > On 08/22/2010 01:36 PM, malc wrote: >>>>> >>>>> But how would you do that? Drop the CODING_STYLE (and accept >>>>> anything)? Switch to a new CODING_STYLE that is widely appreciated and >>>>> so all bikeshedding will cease? Enforce current style? >>>>> >>>> I would suggest we either clean up the existing rule, or switch to the >>>> Linux kernel style, with the explicit exemption that existing code can >>>> keep the 4-char indentation, unless the whole file is converted. I'd >>>> like to avoid a total reformatting of the codebase, but we could look at >>>> it on a file by file base if it becomes relevant. >>>> >>> Sounds reasonable. >>> >>> >> Doesn't to me. >> > > I'm strongly opposed to any reformatting of the tree. > > All it does is break git blame which makes debugging harder without > offering any real benefits. And that's why enforcing the parts of the coding style that are insufficiently consistent with the existing code (mandatory braces, for instance) is a waste of time. Writing our own tools to help with that is an even bigger waste of time. Everyone's free to waste his or her time however he or she pleases, of course. But I respectfully request to refrain from wasting somebody else's time. Yes, we should insist people make their changes blend with the existing code. But making them jump through additional brace-hoops when their changes do blend crosses the line for me.