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 476263858D35 for ; Wed, 15 Feb 2023 14:47:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 476263858D35 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=1676472460; 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=z5NQBmT2q4V+3/A+YSQjnBuLuwC8R0HEt+guK6U3Yxw=; b=H/jmDhOe2VCEaNPddppfSoJRAwn0L7+Rm0VEEbcWtt8nlrjSv7QDj7LGwi085aPgCCY/yz CEh+wgDSQzQuFkw1shXRvKhffziAt+V4r932eyeJyFup8oeSVys8L5lV0KWNkIGq93YtUn MolmSYqaR/H6+uiN7UCI7MMhJkIujcQ= 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) From: Andrew Burgess 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-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: 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