From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id sHdzLd0g62PaTTIAWB0awg (envelope-from ) for ; Tue, 14 Feb 2023 00:49:17 -0500 Received: by simark.ca (Postfix, from userid 112) id B80FF1E221; Tue, 14 Feb 2023 00:49:17 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=Fap3mWOt; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, RDNS_DYNAMIC,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 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 490251E112 for ; Tue, 14 Feb 2023 00:49:17 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7677A3858422 for ; Tue, 14 Feb 2023 05:49:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7677A3858422 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1676353756; bh=+RfmT2mdyA6rCkWYkDhPBfdBLLkcKyLBNt9m1B7cWEU=; h=Date:To:Cc:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=Fap3mWOt/K5jKCjORFuXE2CEA+MadyMH65bcxIYWvxHQjpOYvgcNuWoprG8hI79mv XHKFAXpBMsoQQVDRpHGCJ5laFEaP6chGebGMj+MX1PTtp2e0hXAkYip1u5dvGVpTdH dErhDSyMAvMDh0CrQRqSHNqejZYlgdpO5jgfpN3g= Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id 362B23858D1E for ; Tue, 14 Feb 2023 05:48:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 362B23858D1E Received: by mail-wr1-x42b.google.com with SMTP id o18so14487623wrj.3 for ; Mon, 13 Feb 2023 21:48:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+RfmT2mdyA6rCkWYkDhPBfdBLLkcKyLBNt9m1B7cWEU=; b=qY9dTTnCiIoigCHQLa4d/FQHSDLKrlI4vPJq7EUUFfjMYcUEQyLE6eG7uGO+GEIC7w m5NDN9ASMjAJLz7BLW8Eo7wvZNEYuROFITVREmJ6jIM7T6ewekYuP3HzRun1koQc2oYc x5Gd95MFhWLJnGfaNxyCDDXSDPeF1tHYR+V4qydkBJiGU8TI7aSIlvAYagQohBZ5kloE qYxo3lc4UhVk5XgE//42AXn9WCY72IOvyIIGuWlgDPca0BqRrqZseDPFhFqR+tQw/izV d4hyEkN2XNJ0M6GTsl+PffN8+eyyDdYcvoexf2pQETHbF4Q/56TrskARoXfnWICYGxK/ q9fQ== X-Gm-Message-State: AO0yUKWMyl0UiRV4Gd6aB0pKJcsb3rArsyPrnVq4bg7fmd9O2jhlDTLC FVhgX/Taqp/Uf5puLYOh0+ahLJMTfdp2PrczuA== X-Google-Smtp-Source: AK7set/FQ/YVWY2YB4RRq3IeONc5NkV83yoPpF34JsosLelnK3UrSQikCWAtcEmTSXod4cQ3l++mRw== X-Received: by 2002:a5d:6348:0:b0:2c5:581d:5a1d with SMTP id b8-20020a5d6348000000b002c5581d5a1dmr994848wrw.43.1676353729071; Mon, 13 Feb 2023 21:48:49 -0800 (PST) Received: from takamaka.gnat.com (lfbn-reu-1-488-54.w92-130.abo.wanadoo.fr. [92.130.77.54]) by smtp.gmail.com with ESMTPSA id s7-20020a5d5107000000b002c556a4f1casm5055085wrt.42.2023.02.13.21.48.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Feb 2023 21:48:48 -0800 (PST) Received: by takamaka.gnat.com (Postfix, from userid 1000) id 63D0082254; Tue, 14 Feb 2023 09:48:46 +0400 (+04) Date: Tue, 14 Feb 2023 09:48:46 +0400 To: Luis Machado Cc: Andrew Burgess , Mark Wielaard , Simon Marchi , Joel Brobecker , Simon Marchi via Gdb Subject: Re: Any concrete plans after the GDB BoF? Message-ID: References: <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> <7112932f-4260-2f33-e619-c7130e0abb20@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7112932f-4260-2f33-e619-c7130e0abb20@arm.com> X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Joel Brobecker via Gdb Reply-To: Joel Brobecker Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" > > 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. As long as the the tool is able to do the formatting of a given file using only that one file, the git-hooks are ready. There is a style_checker option which is currently calling a script that does nothing. But if we have some tools that check things such as formatting, copyright header format, etc, it's easy to insert them and reject the commit. The problem is that this arrives too late in the process, IMO, because by then, the review has already gone through. For a formatting issue, one could argue that the change is trivial, and therefore automatically re-approved, but this is not ideal. What we would want is some kind of CI system which, from the moment the developer proposes a patch, gets the change validated through the CI. Style-checking is usually quick, so a good candidate for a CI. But how to integrate that without starting to re-invent one of those existing Git review or Git hosting systems that already exist? What this discussing is showing, IMO, is that the email-based system of proposing and reviewing patches may be fast and comfortable, but has some limitations compared to other more modern systems that seem hard to overcome. We can find technical solutions that overcome those issues, but each time I try this exercise, I find myself thinking the problem has already been solved is there for the taking if only we could accept email-based workflows might be degraded, possibly to the point where it becomes more productive to use the recommended interface (e.g. website). Good or bad, my concern is that the younger generation views emails as antiquated and at the same time they have grown up learning about collaboration using systems such as GitLab or GitHub. I apologize for widening the discussion from code formatter to review system. It's not how I planned this message when I started replying, but it seemed natural to add the comment about how we manage patch submissions and how we do reviews. -- Joel