From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id DA9833858D33 for ; Mon, 13 Feb 2023 15:13:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DA9833858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676301221; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=adKR/+8zz2c0FZwJp/MN7P36LQrBpCO/5Gu8WXG2JNM=; b=MWr6gFZVLC4ZajxI+4yrfiNqNJSGUEg0mDsqhXa0S/VfHkQ4PSXr5MS4tuoG5MPd2b0uae 5U1dMgM7gw21Z6ynpeUDYOQ3+cQY3+tHj9/o/MS+GSrMXOatIyH2nVFKS/gy3pk5Jknl/d pZdQFGutHnFt9BFsqOEZ+/TYkgtKutQ= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-576-8LZXwJnWMTGW7sWUe9BPzA-1; Mon, 13 Feb 2023 10:13:32 -0500 X-MC-Unique: 8LZXwJnWMTGW7sWUe9BPzA-1 Received: by mail-qk1-f197.google.com with SMTP id w17-20020a05620a425100b00706bf3b459eso7680671qko.11 for ; Mon, 13 Feb 2023 07:13:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=adKR/+8zz2c0FZwJp/MN7P36LQrBpCO/5Gu8WXG2JNM=; b=W4teiqT7sZW0au9HLe5Y+pa/0Z4wZvdxwVilEzOCvm90F69pgPUqvLy5natkf1M4Gn B3OML2WSk0CnTE5eEP6h8rPMNzI4zv2F3JD7wgFYsVBnI306X7rNUl/cNsK7iTOJohjm 7ZKw+nJBmGBMBjnEMUmY10tyuISbDTOznQbRA93URumd3SvmTcA6blrnSsN46pNnmaFI VOFdXFghY7zqxlOc6h/SMrciW2ZlCHbsNqMCa4YAkibhRGLuZA8Qz16BP7jRG2N5TKB/ 5UXldTBvXZ5uRy3DUaNu+UjbQewOp9BPf9yAT1knAy+k2n/l18IWvX/XXTXEvvGl+eKW nKjQ== X-Gm-Message-State: AO0yUKU/1zcrOetojBUR3oRGAQHV2Dk8kbuIXAY5D8BYh/gJ+ZBxNlHL AcwI4v8nNBPECuJSSU2cLisfl6GwrG1T7V28dW0z9pNCJ8/Bu6r9HvjH608vsFqGDk6+Q5JDoBE wC6Pmy9UJYoA= X-Received: by 2002:a05:6214:2aad:b0:56e:b16d:ec93 with SMTP id js13-20020a0562142aad00b0056eb16dec93mr6751909qvb.4.1676301211268; Mon, 13 Feb 2023 07:13:31 -0800 (PST) X-Google-Smtp-Source: AK7set+mwiZcYGqQVlmcfeEFhOGbagQWzNLKWfKP0SeepPUYOtxIhQD1Fikk50NoV1PEmmLulFkG7Q== X-Received: by 2002:a05:6214:2aad:b0:56e:b16d:ec93 with SMTP id js13-20020a0562142aad00b0056eb16dec93mr6751865qvb.4.1676301210925; Mon, 13 Feb 2023 07:13:30 -0800 (PST) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id t66-20020a374645000000b007203bbbbb31sm9972102qka.47.2023.02.13.07.13.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Feb 2023 07:13:30 -0800 (PST) From: Andrew Burgess To: Luis Machado , Mark Wielaard Cc: Simon Marchi , Joel Brobecker , Simon Marchi via Gdb Subject: Re: Any concrete plans after the GDB BoF? In-Reply-To: <65409b73-fc6d-9a89-3541-31eb1a0b0791@arm.com> 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> Date: Mon, 13 Feb 2023 15:13:28 +0000 Message-ID: <87bklxtx7r.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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? 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 >>