From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2076.outbound.protection.outlook.com [40.107.21.76]) by sourceware.org (Postfix) with ESMTPS id 61D8D3858D33 for ; Mon, 13 Feb 2023 15:24:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 61D8D3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A+1fANzRPGLvBdAppSzhu8aSVpxOvmWXILdaPDmqBu0=; b=sbW/tjbkCLgVz2hOt4VV8xVbkRF2tRj6e7x89XXECfBGIt8kIMjI5JdGz176Yugyf5kcPREKGHn7bMa70KZSjUVupotyflPDc4Ujicz9UD6jQjX7Yn00AaZ56RbJwJJsl8D+xvkvjFcfXbWVDwjdPpRv71yDz/cs8RzJLn3jKaQ= Received: from AS9PR06CA0036.eurprd06.prod.outlook.com (2603:10a6:20b:463::17) by PAWPR08MB9517.eurprd08.prod.outlook.com (2603:10a6:102:2eb::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.23; Mon, 13 Feb 2023 15:23:57 +0000 Received: from AM7EUR03FT021.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:463:cafe::51) by AS9PR06CA0036.outlook.office365.com (2603:10a6:20b:463::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.24 via Frontend Transport; Mon, 13 Feb 2023 15:23:57 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM7EUR03FT021.mail.protection.outlook.com (100.127.140.243) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.22 via Frontend Transport; Mon, 13 Feb 2023 15:23:57 +0000 Received: ("Tessian outbound 0d7b2ab0f13d:v132"); Mon, 13 Feb 2023 15:23:57 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 09b70322d3ea40a3 X-CR-MTA-TID: 64aa7808 Received: from cbb0f3c81e15.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 4A335D15-3CA2-41BA-A757-4C0FC58EC31F.1; Mon, 13 Feb 2023 15:23:50 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id cbb0f3c81e15.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 13 Feb 2023 15:23:50 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HUdY+l8r+n44PRv38lYTO5ZARAsoQXaxXlozu6dUdqYZqlsmyhL806zhUjt3I6wmISdxp4waaS8iOsbslppiSobkDHFcavO8e+D4HcF9VdiZPa/FxRcD8c4aSSI4qbM4Qd9FXfxGs6ukCgT3NE0COaUsTYpcDLPgDHqZiSqfNeLnkB0DmP6Jqfn/dlofT5qiPPAeiB2QduNl9LorZXDSz8Kg4mBNDSNdOwJkZHalsCJvQgDcHTTyFUPA/h870+TqP+L4azQCk72Z2saoN8fxDpBp7lBpSUM3PwjZN3j0vHdvWCZyaFeOwceNzH8VNeYE9xI2/wY/ntx1KDPbsX+vow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=A+1fANzRPGLvBdAppSzhu8aSVpxOvmWXILdaPDmqBu0=; b=cdxstPbo5bQmO2OOwxamw4R3oiNr1+r9/NTM234w8RK+gRdrpMEmZ0TIWck8f9dhfiDSF+TjGAFkXMBm+BoC6/3ZdAE6Vw0rrdBFNaf28gpfRF87bQLrdGLnaMsp+2dxe0Mjjfh2QoFPdm6nKjfvbnkoLz2XC9uwFPZM2HSLIySOcfpKPoTSRgaiXY5RZw0jj7p08wEB0KrkBwpuYiB86+shhhGbs6VGvhNP2wY4jPxK3HcLw/kA2K7nFrnGRt0yfV6fE/wyD95mpW/UGsScvKZMSfynTEN3Bm/b9PjnyhR2V+ngKjftHmx+u1vv7ufQ3VkkrggnaUu3Qb5QYggNVg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A+1fANzRPGLvBdAppSzhu8aSVpxOvmWXILdaPDmqBu0=; b=sbW/tjbkCLgVz2hOt4VV8xVbkRF2tRj6e7x89XXECfBGIt8kIMjI5JdGz176Yugyf5kcPREKGHn7bMa70KZSjUVupotyflPDc4Ujicz9UD6jQjX7Yn00AaZ56RbJwJJsl8D+xvkvjFcfXbWVDwjdPpRv71yDz/cs8RzJLn3jKaQ= Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) by AS8PR08MB6134.eurprd08.prod.outlook.com (2603:10a6:20b:291::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.24; Mon, 13 Feb 2023 15:23:47 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::bced:32a3:b77e:90a6]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::bced:32a3:b77e:90a6%4]) with mapi id 15.20.6086.024; Mon, 13 Feb 2023 15:23:46 +0000 Message-ID: <7112932f-4260-2f33-e619-c7130e0abb20@arm.com> Date: Mon, 13 Feb 2023 15:23:43 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: Any concrete plans after the GDB BoF? Content-Language: en-US To: Andrew Burgess , Mark Wielaard Cc: Simon Marchi , Joel Brobecker , Simon Marchi via Gdb References: <83485199-965e-7ff5-1dc8-d027b74b56f7@arm.com> <5924814b-2e53-da09-6125-48ac5a5296e7@simark.ca> <87mt5kunum.fsf@redhat.com> <20230212124345.GH2430@gnu.wildebeest.org> <87r0utu6ew.fsf@redhat.com> <65409b73-fc6d-9a89-3541-31eb1a0b0791@arm.com> <87bklxtx7r.fsf@redhat.com> From: Luis Machado In-Reply-To: <87bklxtx7r.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0054.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:152::23) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|AS8PR08MB6134:EE_|AM7EUR03FT021:EE_|PAWPR08MB9517:EE_ X-MS-Office365-Filtering-Correlation-Id: f5c90353-1673-41cc-befd-08db0dd65383 x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: oaBrlfYmu6K8Urigbz4t8QjoP5M6iy1pKXukLNWpoONrCoPQtMEz2t8h9+B5+uJXMRylqG5XJpfK5/Bbb8jeUUzqZu8bsNyd24SSjtDnD542ZH9dbz0sK6O462F/5Z7S/GeiRU8SqMWYAOUOOALaBsP7AIZCR7mK+8GRCEBcpq+8gtBs1JCJvT320sAE60YZyK7NwEMUelQsg66kt3qtebblmYvrZ7GUA1MhCdT+nQyEqqAvZdTOwooBXAgaKPa8t4ImRbNojJL3BGP2JzVTK0YAjzlhRR5rJWM+GZWgbwDiotUbv36PxmOdO3F1Qe3Y+NrbJ0Dc4fXUmBT3puvfU/ZXQz0dWdR6rICBUzEIYURke80uzugppPR+K8CpBkqLfCVUecdYt8vnJy2pMkDKmXtDj2BqVz/tEATJIdpVVaUS36OoacPZ88tL1JVBBl7Z2wprJwjCD/cCwTZzejkxElQHrqutn+2V1WAJUeRaXiWpTSzuDcPz/m2B0OrrYUXveoLNzoq8mkR202uOi4Kau41TPHL57PUl8JTSpeJSnyzbBdvcfhCAyFc06xqr+GM8ROKGVb8j2WcQqYFrW0f4tEwkzSxtXqQlmlzM2g4+wMHDZ6i09cIyb32y/XeT4fxhD67ufal0+OPm79Oobbs349g4oM/xWWou8CBDc/i0z/HlLDKqHCbRUV7nQbWIVcQDl8s2/TAXEYQOzY5oBoBbdZ6N7fX4A4GdHJfALkJ8Zbo= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB3919.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230025)(4636009)(376002)(136003)(366004)(39860400002)(396003)(346002)(451199018)(31686004)(66899018)(83380400001)(6486002)(53546011)(26005)(36756003)(2906002)(6506007)(2616005)(110136005)(54906003)(38100700002)(66946007)(8676002)(66556008)(66476007)(4326008)(186003)(6512007)(478600001)(8936002)(6666004)(44832011)(86362001)(31696002)(41300700001)(5660300002)(316002)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6134 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM7EUR03FT021.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: ab56ce0f-7dd3-444a-5d1d-08db0dd64c40 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NXLm2DMZmCPo6z/f/FAGkGgJ9GcCviEVLh95A+XxiLujC4kwmfyLDAv0e1mRlJpgpRXh+hCnrayVLXQ2O+8vSXMeoryrSWsHN10PPLR5q1R0wSugTQbawnCKQWvptnC1AfaRtUDLwRQ27r9jRRIF4sipPaYSaw7JsjeJvDJ/lze+SHWwXLfqBSZEu7UomQjYUEGw/Ghl/v9Pzr2IwhlN8sgT7OAfcqUKJsC/OL36MOchiXItZ1mbeZqIEN7ehuxrwjRWaRkrZHrkXWl5Yd0Y1jRaoeGPjJsfhi0eaRwDDwrbQnXkfZl2Hd/nqeyyM52LfXH2fYpUqBmO1o/lYXloE4OD54PP8XQar+UTAPgPCrUd7OjHsQo019FGhOUDLFx4IYj7E47Nz0xMU45BHvX13TwU4M7rGlcKwH9EER3c/f+q40A9YMSrg2DWl1GX0rl0U2qW9D1dZBwlcIO2hTYATzW7eHCeUOwFvK+Rj2B+YO2RKJBVSIsNelSpNQYjCCoZB2VeJAV2/vLkh4VhN8tYLJJKidnouX6NeLOs1u8mjEgaFUarHTPBIs7BmMcqq6rE544RiN6TvKcH1/UAHnFdPY45pT3xUr3LjcfnlHtoRgX7TeGoGDidcjAiSr92ciHFFwhpFgIbUI7TVG8RlnDvktP5hl1TYXMcDx/E2zZc+7CVoF/eyn4wPagN4ex0qxBNYR1GolqSrlAJeqAeKLuhw5VLgC7R2HTLqgzpR/bHIRg= X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230025)(4636009)(136003)(396003)(376002)(39860400002)(346002)(451199018)(40470700004)(46966006)(36840700001)(47076005)(83380400001)(82310400005)(2616005)(356005)(86362001)(40460700003)(36756003)(31696002)(40480700001)(36860700001)(81166007)(82740400003)(31686004)(5660300002)(2906002)(44832011)(70206006)(4326008)(54906003)(70586007)(8936002)(316002)(110136005)(8676002)(41300700001)(336012)(6486002)(26005)(53546011)(186003)(6506007)(6666004)(6512007)(478600001)(66899018)(43740500002);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Feb 2023 15:23:57.7581 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f5c90353-1673-41cc-befd-08db0dd65383 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM7EUR03FT021.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB9517 X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FORGED_SPF_HELO,KAM_DMARC_NONE,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,RCVD_IN_VALIDITY_RPBL,SPF_HELO_PASS,SPF_NONE,TXREP,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2/13/23 15:13, Andrew Burgess wrote: > Luis Machado writes: > >> On 2/13/23 11:54, Andrew Burgess via Gdb wrote: >>> Mark Wielaard writes: >>> >>>> Hi Andrew, >>>> >>>> On Sat, Feb 11, 2023 at 05:13:37PM +0000, Andrew Burgess wrote: >>>>> Simon Marchi via Gdb writes: >>>>>> I would suggest mandating one version, and for that version to >>>>>> continuously be the latest stable version of clang-format, like we do >>>>>> for Black. When a new version comes out, we don't have to wonder if / >>>>>> when we move the next version. Someone just pushes a patch re-formating >>>>>> the code to the next version, if there are some differences. It keeps >>>>>> the overhead to a minimum. >>>>> >>>>> I dislike our policy of using the latest version of black, and would >>>>> argue that always using the latest version _increases_ the overhead, >>>>> rather than reducing it. >>>> >>>> Have you found the python formatting flagged by black "unstable"? >>> >>> No. >>> >>>> The >>>> buildbot uses the latest black as comes with fedora stable and I don't >>>> remember it flagging issues on upgrades. But maybe it hasn't been >>>> running for long enough? It has been running since July last year. Are >>>> you running a much older black? Does it produce different formatting? >>> >>> No. And we don't have a huge volume of Python code. Both of these >>> points (stability + small code size) is why I've never said anything. >>> That doesn't mean I think the idea of constantly chasing the latest >>> version is a good idea. >>> >>> In fact, it probably makes it worse. I _don't_ update black. Why? >>> Because what I have just works. When something does change I'll >>> certainly commit some incorrectly formatted code. >>> >>> Does that really matter? I don't think so. It'll be an easy fix, it's >>> just annoying. >>> >> >> I suppose that's the point of introducing auto-formatters. If some incorrect formatting is >> pushed alongside some code, it is not a big deal. But having to manually chase some format and fix it by hand (as we do now) >> before it can go in is potentially worse. >> >> It is also a burden for reviewing. It doesn't seem like the kind of thing people should be doing manually at >> this point in time. > > I've never bought this argument. > > This makes perfect sense in a corporate environment, where you can know > everyone is using the same tools. But for a distributed project, I > don't think we can rely on every contributor using, or remembering to > use the formatting tools correctly. > > Ideally we don't want every commit, or a daily commit, where someone > runs clang-format and posts the fix (obviously this will happen, but the > goal would be to keep this to a minimum, right?), so reviewers still > need to think about formatting when reviewing patches. > > For larger patches, this is easy enough, I install the patch in my local > tree, run clang-format, and if any changes show up, I immediately reject > the patch. But I _still_ have to think about formatting, I just do > different things. > > For smaller patches that I might previously have reviewed in my email > client; well now I _really_ need to think about formatting, because if I > see anything that's even slightly weird, I can no longer make a > judgement call on if it's formatted reasonably, I absolutely _have_ to > install the patch and clang-format it in order to check it was formatted > correctly. > > Now, where this might save time is if we had some kind of git hook which > could validate the code was formatted correctly and reject push attempts > if they are not formatted. Then I could stop thinking about > formatting. But until then .... I don't think reviewers will be able to > stop asking: is this formatted correctly? > That's what I have in mind. Some pre-commit hook that checks/does things. Obviously we're not there yet, but that would be the most convenient way. I think anything that needs to be checked by hand wouldn't be an improvement compared to the current process. > Thanks, > Andrew > >> >> Obviously the burden is different for different people and different setups. >> >>>> >>>>> If I had a choice then, personally, I'd vote against using clang-format >>>>> at all, but it feels like there's a majority in favour, so if we do have >>>>> to go down this route, I'd rather we adopted the same policy as for >>>>> autotools and C++ versioning. That is, pick something that works for >>>>> us, and commit to it over the medium term. That way at least, I can >>>>> build a single version of clang-format and know that it's going to last >>>>> me for a while. >>>> >>>> But is there already a verions that works? I think that is the >>>> difference between the python black formatter for python code and the >>>> clang-format for C and C++ code. It seems for the python code there is >>>> a supported format that matches what is used, but for clang-format >>>> there is not (yet?). >>> >>> I'm a little confused by your point here. You (correctly) point out >>> above that the output from black is pretty stable across versions. >>> >>> But here it almost seems like you're suggesting that we should chase the >>> latest clang-format because it doesn't (currently) support the style we >>> use. Which would seem to suggest we are hoping it _will_ change, which >>> suggests output instability, which, surely, is a bad thing? But like I >>> said, I didn't really understand the question here... >>> >>> I would suggest that if we did start using clang-format, then that >>> indicates we are happy enough with its output. If we're happy enough >>> with its output today then I think we can be happy with the output for 1 >>> (or even 2) years before looking to see if an updated version offers >>> improved formatting. >>> >>> Remember, there are folk who maintain out of tree forks of GDB. And >>> though we shouldn't make policy choices just to accommodate them, I'd >>> hate for us to go out of our way to make their lives harder just for the >>> sake of chasing the latest version of some tool. >> >> I think Mark's point is just that we haven't settled on a particular gnu-for-clang-format rule set. >> >> Yes, there is a gnu style there already, but we haven't decide if it is good enough or not. >> >> We just need to play with it for a bit and see if people overall think it is good enough. > > OK. > > Thanks, > Andrew > >> >>> >>> Thanks, >>> Andrew >>> >