From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id 4CF2A3857019 for ; Tue, 18 Jul 2023 13:19:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4CF2A3857019 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-6687446eaccso5688852b3a.3 for ; Tue, 18 Jul 2023 06:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689686385; x=1692278385; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=RlbPSt/9wPM2TDi7824kvMLSjJ9UvpOMUMoMYL/5BT8=; b=lp7+pLqjBttYDbYC+X0U1jeIS1D6DmdNU2ZRXxEzIq0hA3IpxgEDF4WAhX87mR6Iyo 6w5JdCo+hYCZwrxk7qLfM7VWWnzDKxZSIFEcYfNmcxjsnHzgRCWv3aIFkcKviwjl7/3O kPPSsZp7+J9Am6FuTKvhf7rLZzvoOG4Nf24jCNeRRdwQ3IKd64fsdwit+p5HcBnud0wb ZoQ/rd/BSPT6OrnkuWesuSDp4ohAKv9A0jIw110pMyeOK+f5Pkdaj28ZcDF2uSqSw6Ze egwdDs6e8X4lX0ms3o+Tqx9b7Bf4uicHAM82HLB/glRLaFKeEZkBrsueDBXQrSFH2Jve gqPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689686385; x=1692278385; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RlbPSt/9wPM2TDi7824kvMLSjJ9UvpOMUMoMYL/5BT8=; b=jT/6Ld89lXWRpVhoaLEIO5m4PJ3qhKTLuxOX7puzhwtOTPIqxa8XaMf2de6BupNKQ9 n1WmdnmnwF+rnc43Q/ncCspiDY6vp1Q1UcFBKayvRWiKJf2QBOb62oW28eVEB7Tuc/vQ 8tPxCsVVPR1Ui2X6e4YvHsaK5I0A5SUMHq7kUORPYSDYA4UwjlGSjn3SDID3txVCQci5 CkAJgjs2w8VbVQD4ksmUzfULbQxCA0dcHtKY35TDZDywbyU25ZWiVf4wtaTANurOho6c 7urFaPZL6Pn19SGmztIRzvuJkI1tGQh0UHV3XsLz+p5btU+inbXHwoZuXqeZSMKhKgtk nV6g== X-Gm-Message-State: ABy/qLZkZFCJi4kKA3bs435OM6QQX34fqJJ0giAU74cmXyh0voaSQB1d ybp/TyPx0Kci7XOv2k3PNOA= X-Google-Smtp-Source: APBJJlFnGpOi5H+RWPIkhUAxms0E/uNrOFiaAScFCLhDPqkMd5NRU+pjbT/S/xCIYehV3yDGTwQq2g== X-Received: by 2002:a05:6a00:1583:b0:681:c372:5aa4 with SMTP id u3-20020a056a00158300b00681c3725aa4mr20715108pfk.27.1689686384633; Tue, 18 Jul 2023 06:19:44 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id w23-20020aa78597000000b006815fbe3245sm1536540pfn.37.2023.07.18.06.19.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Jul 2023 06:19:44 -0700 (PDT) Message-ID: Date: Tue, 18 Jul 2023 07:19:42 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: Core Toolchain Infrastructure - Services for glibc Content-Language: en-US To: Jakub Jelinek , Siddhesh Poyarekar Cc: Konstantin Ryabitsev , Florian Weimer , Carlos O'Donell via Libc-alpha , Carlos O'Donell , Joseph Myers , "Ryan S. Arnold" , Paul Eggert , Maxim Kuvyrkov , Andreas Schwab References: <45e98807-908f-0968-b6fe-5dbb0af265b1@redhat.com> <87ttu6oh9j.fsf@oldenburg.str.redhat.com> <20230714-card-radium-prow-27d2f1@meerkat> <2b743481-4dc3-07a1-fe65-a32a9d1df09a@gotplt.org> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 7/18/23 06:26, Jakub Jelinek via Libc-alpha wrote: > On Tue, Jul 18, 2023 at 07:47:37AM -0400, Siddhesh Poyarekar wrote: >> On 2023-07-14 11:34, Konstantin Ryabitsev via Libc-alpha wrote: >>>> Can we keep using the AdaCore hooks? Or would they have to run on the >>>> side somehow? Who is going to implement changes to the AdaCore scripts? >>> >>> This is the main point of contemplation -- we do not currently support custom >>> hooks on the server side: >>> >>> - they tend to significantly slow down pushes >>> - they run extensive codebases with the same permissions as the owner of the >>> repositories, significantly increasing security risks >>> >>> Our recommendation was to move all CI tasks to a system that is better suited >>> for it. For example, CI can run on a patchwork system and the pre-commit hook >>> can then check that each commit matches a patchwork entry that passed CI. >> >> This would mean porting AdaCore hooks to a patchwork trybot. This would be >> an acceptable solution for glibc, but I'm not sure how useful this would be >> on the whole since gcc doesn't use patchwork as extensively at the moment. >> Also, we need to figure out who's going to do this. > > It is definitely not acceptable for gcc, we strongly rely on server side > pre-commit hooks for various different tasks. BUt the key (I think) is they're not trybot/CI style hooks. They're doing things like wiring up commits to the lists/bugzilla, verifying ChangeLog bits and the like. I think the point is that any hooks need serious thought about what they do and the attack surface they represent. So for example firing off pre-commit CI, not advisable. Having a hook that queries another system for the state of pre-commit CI may be reasonable. I would think that verifying ChangeLog format might fall into the reasonable space. Not sure about lists/bz integration hooks. jeff