From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37496 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OlRLh-0003bQ-RI for qemu-devel@nongnu.org; Tue, 17 Aug 2010 14:57:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OlRLM-00005N-6X for qemu-devel@nongnu.org; Tue, 17 Aug 2010 14:57:05 -0400 Received: from mail-qy0-f173.google.com ([209.85.216.173]:56121) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OlRLM-00005G-2S for qemu-devel@nongnu.org; Tue, 17 Aug 2010 14:57:04 -0400 Received: by qyk5 with SMTP id 5so1005796qyk.4 for ; Tue, 17 Aug 2010 11:57:03 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4C6A94D0.2090201@redhat.com> References: <4C6A4291.1020105@redhat.com> <4C6A8CD8.2080701@codemonkey.ws> <4C6A94D0.2090201@redhat.com> From: Blue Swirl Date: Tue, 17 Aug 2010 18:56:43 +0000 Message-ID: Subject: Re: [Qemu-devel] [PATCH 0/5] CODING_STYLE amendments Content-Type: text/plain; charset=UTF-8 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jes Sorensen Cc: Miguel Di Ciurcio Filho , qemu-devel On Tue, Aug 17, 2010 at 1:55 PM, Jes Sorensen wrote: > On 08/17/10 15:21, Anthony Liguori wrote: >> On 08/17/2010 03:04 AM, Jes Sorensen wrote: >>> On 08/13/10 20:02, Blue Swirl wrote: >>>> I fully agree on the need of change and support your excellent idea. >>>> There are other ways to solve the problem, but I believe we need more >>>> order than more chaos. Perhaps we the QEMU developers should appoint >>>> you the Guardian of the CODING_STYLE, and add a rule that no patch >>>> shall be committed without your CS-Acked-by line? >>>> >>> I don't think this would ever work, it is begging for trouble relying on >>> one person to review all patches for this. >>> >>> While I agree coding style is good since it enforces consistency, there >>> are plenty problems with the old rules >> >> To be perfectly honest, we have enough hard problems to solve in QEMU. >> We're spending a lot more time on coding style than we probably need to :-) > > I think we are in full agreement here, I am really just worried that we > add additional procedures here that will slow down the real development. Either the braces rule in CODING_STYLE is downgraded to recommendation, or some kind of new order is introduced. Current situation is unfair.