From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48750 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnXoA-0000iR-J7 for qemu-devel@nongnu.org; Mon, 23 Aug 2010 10:15:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnXo9-0007Q4-0S for qemu-devel@nongnu.org; Mon, 23 Aug 2010 10:15:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54813) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnXo8-0007Pg-Pw for qemu-devel@nongnu.org; Mon, 23 Aug 2010 10:15:28 -0400 Message-ID: <4C728278.5050500@redhat.com> Date: Mon, 23 Aug 2010 17:15:20 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/5] CODING_STYLE amendments References: <4C6A4291.1020105@redhat.com> <4C6A8CD8.2080701@codemonkey.ws> <4C71550F.6080602@redhat.com> <4C716F43.8070805@codemonkey.ws> <4C717A6C.9080805@codemonkey.ws> <4C718AF7.6000403@redhat.com> <4C727DC5.9010805@redhat.com> <4C727F9E.2080203@redhat.com> <4C72808B.4090500@redhat.com> In-Reply-To: <4C72808B.4090500@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jes Sorensen Cc: Markus Armbruster , qemu-devel , Blue Swirl , Miguel Di Ciurcio Filho On 08/23/2010 05:07 PM, Jes Sorensen wrote: > On 08/23/10 16:03, Avi Kivity wrote: >> On 08/23/2010 04:55 PM, Jes Sorensen wrote: >>> Well with the inconsistency we have now, what is the right iron fist to >>> apply? Demand the code is consistent with the file you edit or that it's >>> consistent with whats in CODING_STYLE, even if it means that what you >>> apply is completely different to the rest of the file? >>> >>> That is the part I think needs to be decided upon in all of this. >> Patch lines that start with ^\+ should be consistent with CODING_STYLE. >> The maintainers may allow exceptions in certain cases, but contributors >> shouldn't expect this. Use common sense where available. >> > Right, in my book common sense is to be consistent with the file I am > editing, as long as the file isn't in gross violation of CODING_STYLE, > but maybe my sense just isn't that good. I'd have said the opposite - if the file _is_ in gross violation, mixing styles would make it unreadable. If it's just slightly different then using C_S would improve it incrementally. -- error compiling committee.c: too many arguments to function