From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29795 invoked by alias); 15 Sep 2014 13:50:09 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 29783 invoked by uid 89); 15 Sep 2014 13:50:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 15 Sep 2014 13:50:07 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id F2AB3116284; Mon, 15 Sep 2014 09:50:05 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CXpKp8X6VKAi; Mon, 15 Sep 2014 09:50:05 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id AC588116206; Mon, 15 Sep 2014 09:50:05 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 412A340E17; Mon, 15 Sep 2014 06:50:04 -0700 (PDT) Date: Mon, 15 Sep 2014 13:50:00 -0000 From: Joel Brobecker To: Thomas Schwinge , Gary Benson , bug-hurd@gnu.org, gdb-patches@sourceware.org Subject: Re: [PATCHv3,Hurd] Add hardware watch support Message-ID: <20140915135004.GJ4871@adacore.com> References: <20140910224919.GP3244@type.youpi.perso.aquilenet.fr> <874mwcpvsy.fsf@schwinge.name> <20140912180054.GB4448@type.youpi.perso.aquilenet.fr> <20140912200141.GH4871@adacore.com> <20140912211354.GI3202@type.youpi.perso.aquilenet.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140912211354.GI3202@type.youpi.perso.aquilenet.fr> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-09/txt/msg00499.txt.bz2 > Seeing a submission to gdb getting stuck on missing line breaks got me > a bit on my nerves. Fortunately it wasn't only about that, but also > important changes, so I carried on, but having to resubmit only for > missing spaces or new lines would have been really hard to me, since I > don't really plan to submit many patches to gdb, and I know I'll > always make this kind of mistakes since I'm submitting patches to a > lot of various projects with very differing coding styles. I understand the fustration, and I certainly would agree if you said that GDB is very particular with its CS. Aiming for a consistent coding style is important for long-term maintainability, though, which is why we almost systematically mention violations we see. If it makes you feel any better, we make mistakes too, sometimes, and have to re-edit as a result. One thing I will say, however, is that I often let go of minor violations, and only mention them if there are other adjustments I'd like to request in the same area. And I know others can be the same. So we try not be be overly picky (you may not believe me on that one ;-)!). As Sergio mentioned, we do not have a script we can use to check coding-style violations. We would very much like to have one, but no one really sent anything so far. What I can do to help is being your CS corrector - just send me your patch privately before submitting, and I will fix all CS violations for you. Another important part I can see contributing to the fustration is review delays. I can see how trivial requests can be extra fustrating if you feel like your patch is being delayed quite a bit because each review cycle is very long. You can help with that by pinging us. The accepted practice is to ping after a week or two, and every week thereafter. -- Joel