From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 324A43858D34; Wed, 1 May 2024 21:04:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 324A43858D34 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 324A43858D34 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714597494; cv=none; b=bgoN+sdvCBGKAzwoLvJu9sxSdVs4QhrXf2NaZ8dTmToJ7HMrGbNH/QFQVumBWgREbTXPlen1wnIgAgo8hq9+HFG5angPCjwxaxYhVM78YnM3/NOG60UWXk9QdbEQQkTHefE4VKAFz88/kpKlwvHDnjY2SxNe4mbWrAEpV0XeDnE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714597494; c=relaxed/simple; bh=CuGbCzqdv/KCmVuYK5bWaK8iYl+5dLHVnhoX8GIesE4=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=SOFOuCmfAt9OLv5ltqp0e3Rs+NS75Qcji3nZ1g3qEtfNBPhhZ6Up9boRS/fPAsln5lo+iVHxcfQoT17hro1QdlNQUQ3ayVMsilIQzt7djIyYVBDhLBDAByLa1P8zdVXNM0JIYq7LJPSZXl4PVps5LeiyxY/SVCNz2C4iOA38n2s= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1714597482; bh=CuGbCzqdv/KCmVuYK5bWaK8iYl+5dLHVnhoX8GIesE4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=CtCdbEFjVfEiIbmh25RdUYXkB6x8OVyys1Japj0UAFFFhhy+F032P4/vQSUuGEdwQ bHdue9BPKJt2tRRXepd57fiZWLJ1xuu7VVJAa4M+uuV0aYtdkF6qoy9yZ4A/VkdMVN 9rBVmG6S4IjprwzOVRsrVn/tMrYENCtAt1rP5Kk0= Received: from [10.0.0.11] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id DAE6A1E092; Wed, 1 May 2024 17:04:41 -0400 (EDT) Message-ID: <64d0e314-f4e9-4c63-90dd-67a05749e12e@simark.ca> Date: Wed, 1 May 2024 17:04:41 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Updated Sourceware infrastructure plans To: Overseers mailing list , Mark Wielaard Cc: Tom Tromey , Jeff Law , Joseph Myers , Jonathan Wakely , libc-alpha@sourceware.org, Jason Merrill , gcc@gcc.gnu.org, gdb@sourceware.org, binutils@sourceware.org References: <20240417232725.GC25080@gnu.wildebeest.org> <20240418173726.GD9069@redhat.com> <87v849qudy.fsf@tromey.com> <87wmooep76.fsf@tromey.com> <0347e05a-94c6-4ecc-aa8f-cc90358a813d@gmail.com> <20240501202008.GA6469@gnu.wildebeest.org> <874jbh45l8.fsf@tromey.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <874jbh45l8.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,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: On 2024-05-01 16:53, Tom Tromey via Overseers wrote: > Mark> See also https://sourceware.org/bugzilla/show_bug.cgi?id=30997 > Mark> We really should automate this. There are several people running > Mark> scripts by hand. The easiest would be to simply run it from a git > Mark> hook. patchwork comes with a simple script that just calculates the > Mark> hash and pings patchwork, which can then mark the patch associated > Mark> with that hash as committed. If people really believe calculating a > Mark> hash is too much work from a git hook then we can also simply run it > Mark> from builder.sourceware.org. We already run a builder for each commit > Mark> anyway. It would just be one extra build step checking the commit > Mark> against patchwork. > > There's just no possibility this approach will work for gdb. It can't > reliably recognize when a series is re-sent, or when patches land that > are slightly different from what was submitted. Both of these are > commonplace events in gdb. > > Tom IMO, asking to always post the committed version as is (effectively preventing doing "pushed with those nits fixed", or solving trivial merge conflicts just before pushing) just to make patchwork happy would be annoying and an additional burden, and noise on the mailing list. The Change-Id trailer works very well for Gerrit: once you have the hook installed you basically never have to think about it again, and Gerrit is able to track patch versions perfectly accurately. A while ago, I asked patchwork developers if they would be open to support something like that to track patches, and they said they wouldn't be against it (provided it's not mandatory) [1]. But somebody would have to implement it. Simon [1] https://github.com/getpatchwork/patchwork/issues/327