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 0A9EC3858426 for ; Mon, 13 Feb 2023 11:54:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0A9EC3858426 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=1676289291; 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=GHYE2BduLS2BwQClLTQzLN6iQI6plKXhzWA7qh3q80Q=; b=aqYcBwpS4znqoKHkGd5hpuWMyFQvlG9aAtTbtVrtIlBEnfblKfF26kqiyHFOg2Godr6AS5 ju8yUKr+ARQ+Oq+W5uJo5hg3TImS6CTF42sf7GaNIUr9WfBayxjv9BdtHk5xo6gBBJ8RBS ysW03vnSgq3RwBtNDhZOcE6VxMndIjA= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-32-WEPC85o-MbOw5CFaCbk7Iw-1; Mon, 13 Feb 2023 06:54:50 -0500 X-MC-Unique: WEPC85o-MbOw5CFaCbk7Iw-1 Received: by mail-qv1-f70.google.com with SMTP id 98-20020a0c806b000000b0056c2797aa8bso6427120qva.2 for ; Mon, 13 Feb 2023 03:54:50 -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=GHYE2BduLS2BwQClLTQzLN6iQI6plKXhzWA7qh3q80Q=; b=NB8Zj3wnBE9dAzcS8nTzTC5Lb8IYmSd/1Mn5x15PuHuIVf27ev048HvUKRtjbTJvG8 h6z2gQNTaqGZw7pyHVA6nan9pkF7qWRCZaF1sKml5xT7HUDEDjN7n7CFAqvd9ZQI+ZIp DTCuZSKOby8RUIuoDQu3yQ4hHfT5G5L6esquIMlQk+X9deDNboK0YQlL7bspBCL9WEHq 7jXZhzIWGLIBo6HpzSefu+cUjiqvSNmlWYaw7rCJawhacWafKWjb37OkJSkEShUfhxHK TKb4qpiIOQ0C9pGUKieQGPYydpOxJY7hCXlg7gUFf6KfcSnYNOloDHKZMBU+uPLSCiRW SjfA== X-Gm-Message-State: AO0yUKVaHfXnPvbR3vq1RD1Xwumspq/0Hlk3yaaCPvsLgP5hHsRa8LbZ STwcjrUpWf9ZhHA/zwFJAlnvz/nThpetqtYcxv08L6S7MtBkUQtCNRTwlVJQxiO1oRUlVN77EDW GO5+BVHIO/P8= X-Received: by 2002:ac8:5842:0:b0:3ba:38:2f59 with SMTP id h2-20020ac85842000000b003ba00382f59mr45647231qth.2.1676289290054; Mon, 13 Feb 2023 03:54:50 -0800 (PST) X-Google-Smtp-Source: AK7set/qnpoBu5Dja/q87p1ESuCQ+slBS0iSwgF45sesH1UjaukElv/oaW6rb8eLbvTcuNETD+ZWRg== X-Received: by 2002:ac8:5842:0:b0:3ba:38:2f59 with SMTP id h2-20020ac85842000000b003ba00382f59mr45647210qth.2.1676289289804; Mon, 13 Feb 2023 03:54:49 -0800 (PST) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id f4-20020ac840c4000000b003b9bb59543fsm9021262qtm.61.2023.02.13.03.54.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Feb 2023 03:54:49 -0800 (PST) From: Andrew Burgess To: Mark Wielaard Cc: Simon Marchi , Joel Brobecker , Simon Marchi via Gdb Subject: Re: Any concrete plans after the GDB BoF? In-Reply-To: <20230212124345.GH2430@gnu.wildebeest.org> References: <83485199-965e-7ff5-1dc8-d027b74b56f7@arm.com> <5924814b-2e53-da09-6125-48ac5a5296e7@simark.ca> <87mt5kunum.fsf@redhat.com> <20230212124345.GH2430@gnu.wildebeest.org> Date: Mon, 13 Feb 2023 11:54:47 +0000 Message-ID: <87r0utu6ew.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.7 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: 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. > >> 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. Thanks, Andrew