From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id SLpRGvoPiGAoBgAAWB0awg (envelope-from ) for ; Tue, 27 Apr 2021 09:22:02 -0400 Received: by simark.ca (Postfix, from userid 112) id 5EFF01F11C; Tue, 27 Apr 2021 09:22:02 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 5E2CC1E01F for ; Tue, 27 Apr 2021 09:22:01 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BAC873894432; Tue, 27 Apr 2021 13:22:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BAC873894432 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1619529720; bh=fZ+wh0jijuFFrFXyx+posTsjirhcfVragPNywWA1Cm4=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=LdvL7OEbd2cuQoSUQ9uxFJkml10jDY52oxQEPkSw19Bc+wtQexNjWH+K0czp9Fo2B xZ/xqS9DLKELYzVxH1J5UNPbfu4jLPz8LdyKkBVKYUHyZruPAzvYpgxnGJ9qXuX475 8oFaS1+MLp8PE1lGo8gvYodM91xvnoku01eFVUys= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 4D3CA3894432 for ; Tue, 27 Apr 2021 13:21:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4D3CA3894432 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 13RDLpJK032162 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Apr 2021 09:21:56 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 13RDLpJK032162 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 296F61E01F; Tue, 27 Apr 2021 09:21:51 -0400 (EDT) Subject: Re: Proposal: format GDB Python files with black To: Andrew Burgess References: <20210426162149.GU2610@embecosm.com> <20210426175022.GV2610@embecosm.com> <20210427075444.GW2610@embecosm.com> Message-ID: Date: Tue, 27 Apr 2021 09:21:50 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210427075444.GW2610@embecosm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Tue, 27 Apr 2021 13:21:51 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" > I have no objections to adopting the use of black, my only request > would be that we formally make it a policy that "rogue" re-formatting > hunks, as we discussed above, should be fixed in a separate commit, > and not included in random patches. > > For me, one of the great things about working on GDB is the generally > good quality of the commits, and I feel that if commits start > including extra reformatting this would be a step backwards. I agree. I thought it was kind of obvious, because it's a continuation of what we do today: if somebody includes an unrelated formatting change in a patch, you'll tell them about it. But it's true that the risk of it happening with an automated is perhaps greater, as people will run the tool and not carefully check the output. I happen to carefully check the diff of my patches before sending them, but maybe not everyone does that. So I'll make sure to include that in the "rules to follow" for re-formatting. > Never mind, given the above I think you've answered my questions. > > Thanks for your time, Thanks for the questions, you raised good points I overlooked. Simon