From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id aLl+AKrw7GPUmTMAWB0awg (envelope-from ) for ; Wed, 15 Feb 2023 09:48:10 -0500 Received: by simark.ca (Postfix, from userid 112) id F31CC1E221; Wed, 15 Feb 2023 09:48:09 -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=NZglBnv9; 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 965A91E110 for ; Wed, 15 Feb 2023 09:48:09 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D35343858004 for ; Wed, 15 Feb 2023 14:48:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D35343858004 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1676472487; bh=z5NQBmT2q4V+3/A+YSQjnBuLuwC8R0HEt+guK6U3Yxw=; h=To:Cc:Subject:In-Reply-To:References:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=NZglBnv9dQq1kXd8uFbfymo9iV8hp2guCRI8dDRTVSC3lTanyUWbyulSULz3kLcrQ IBLUy9N9d4oGIvhPEm3DR7/lrV7BOAGXkE4TSWEsSj6MilfGCerr99B1geEueIvX2Y 9AoFXKC4HbyDMHxfvJbUiWnWM1/ActF5Jz5ncBfs= 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 476263858D35 for ; Wed, 15 Feb 2023 14:47:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 476263858D35 Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-448-gFLQuRxYOPa_97lFAcoELw-1; Wed, 15 Feb 2023 09:47:38 -0500 X-MC-Unique: gFLQuRxYOPa_97lFAcoELw-1 Received: by mail-qk1-f198.google.com with SMTP id c9-20020a05620a11a900b0072a014ecc4aso11568311qkk.18 for ; Wed, 15 Feb 2023 06:47:38 -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=z5NQBmT2q4V+3/A+YSQjnBuLuwC8R0HEt+guK6U3Yxw=; b=4f8K4SOSj00kGz9yQwvSaHrre+ggjP8kimnZh0qJFZchuMpCNRcf2Z5+BYd5e+kfwr G887rxNQygD2Wd7c4HmqIZtePTZudbXaaF3DxKaI+ljk4KjUwb9gLMgi4j9u2XnZigQp mzU/ySXj4e+V11QU13+C/kZmakqYXf/qkvpqwwQrz1eajYERjHmGXed2Th89NNgum8Fy kKL2BIgEqQBZ406q45jQXFNg2xvNa0xIYDfSEIIpOw+mIKlDdjVMGGhtAyhqEqyeaVrS cda2NB2zbBuYKtEStYqJW+87rwSMyD3wpTzNoj+IIpz0JLJSxwXqw2iZyQck9PGBXJp9 Xqxw== X-Gm-Message-State: AO0yUKUoYBmjv2/+wKJdjkxF1O5KB3ah/UF/Ov+TKR1WslkPB0btwatm eiTN34TbEzuR3XC6eVgTMH3bJiSfmu+pPMiLNgSWvEtpLRR1VesOWFR1Z65e+JrK8z+kpZnFjbT eAAxers0YXY8= X-Received: by 2002:a05:622a:174d:b0:3ab:a047:58ee with SMTP id l13-20020a05622a174d00b003aba04758eemr3837777qtk.25.1676472458310; Wed, 15 Feb 2023 06:47:38 -0800 (PST) X-Google-Smtp-Source: AK7set9gzjW+Hfsu3bv3fo60NxuM7dEPWh5VdmwyvuFCCWTXEWWetH6D2C4K4OIVM1bNjXtf1Ih2Sg== X-Received: by 2002:a05:622a:174d:b0:3ab:a047:58ee with SMTP id l13-20020a05622a174d00b003aba04758eemr3837731qtk.25.1676472457944; Wed, 15 Feb 2023 06:47:37 -0800 (PST) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id m123-20020a375881000000b0073b4cdb0745sm5019138qkb.116.2023.02.15.06.47.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Feb 2023 06:47:37 -0800 (PST) To: Joel Brobecker , Luis Machado Cc: Mark Wielaard , Simon Marchi , Joel Brobecker , Simon Marchi via Gdb Subject: Re: Any concrete plans after the GDB BoF? In-Reply-To: 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> Date: Wed, 15 Feb 2023 14:47:35 +0000 Message-ID: <87zg9fkmt4.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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: Andrew Burgess via Gdb Reply-To: Andrew Burgess Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" Joel Brobecker writes: >> > 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. Whether the commit should be reformatted and auto-approved is orthogonal I think to whether we should have an auto-format checked as part of the commit hook. As long as folk are able to manually push to master then the process is open to (honest) user mistakes, and we should, as far as possible aim to have systems in place to guard against those mistakes. So having git refuse to accept a commit that is incorrectly formatted would be a good thing; though I 100% agree with you that ideally we would ALSO have tools that could auto-check the formatting earlier in the process and bring that to the developers attention. > > 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). 100% agree. > > 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'd avoid the word 'antiquated' as it (too me) seems to have negative connotations. But I agree, many developers are familiar with a pull-request development model, and I think it has many advantages over our current way of doing things, I'd be very much in favour of switching to a PR style system. That doesn't mean there aren't also advantages to how we do things today. Thanks, Andrew