From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZlyx-0001SA-Un for qemu-devel@nongnu.org; Wed, 09 Sep 2015 16:28:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZlyt-00028j-S1 for qemu-devel@nongnu.org; Wed, 09 Sep 2015 16:28:39 -0400 Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:35518) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZlyt-00028V-Lh for qemu-devel@nongnu.org; Wed, 09 Sep 2015 16:28:35 -0400 Received: by wicge5 with SMTP id ge5so257377wic.0 for ; Wed, 09 Sep 2015 13:28:35 -0700 (PDT) Sender: Paolo Bonzini References: <1441619584-17992-1-git-send-email-pbonzini@redhat.com> <1441619584-17992-3-git-send-email-pbonzini@redhat.com> <55ED8EA0.6040400@redhat.com> <55ED9DA9.80208@redhat.com> <55EDA144.8000505@redhat.com> <87lhci5k3q.fsf@blackfin.pond.sub.org> <55EDB601.7080903@redhat.com> <87r3mayxb1.fsf@blackfin.pond.sub.org> From: Paolo Bonzini Message-ID: <55F09670.9040405@redhat.com> Date: Wed, 9 Sep 2015 22:28:32 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/4] CODING_STYLE, checkpatch: update line length rules List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Markus Armbruster Cc: Thomas Huth , QEMU Developers , Andreas Faerber , Eduardo Habkost On 09/09/2015 19:22, Peter Maydell wrote: > On 7 September 2015 at 18:05, Markus Armbruster wrote: >> Paolo Bonzini writes: >>> That said, and even though Thomas obviously hasn't read the previous >>> discussion, :) I do believe that 76 characters is too strict a limit. >> >> It's not a strict limit, it's a warning. The strict limit is 90. > > I tend to bounce patches on review for checkpatch warnings... > I don't make much distinction between a warning and an error. Doing something about this is the point of this series. As a start, it enables a few more warnings (patch 3) so that maintainers start seeing them and get used to them. Some may reject patches altogether based on the warnings, some may not. With just a few exceptions (tabs, line lengths, braces) it makes a lot of sense to fix warnings in the whole tree with a single sweeping change. If we agree about this, we can upgrade warnings to error at the time of the fix, or even before. Ultimately, warnings should be used only for things that are _really_ subjective, so that we can aim at an error-free (but not warning-free) "checkpatch -f". Paolo